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Introduction 


S 


Thank you for purchasing the Cisco Security Monitoring, Analysis, and Response System (MARS) 
Local Controller. appliance. This guide will help you get the most value from your MARS Appliance. 


Note 


The information in this document referring to a “MARS appliance” also applies to MARS use as Local 
Controller in a Global Controller architecture. 


The MARS Appliance 


The Cisco Security Monitoring, Analysis, and Response System Appliance (MARS Appliance)— the 
MARS 20, MARS 50, MARS 100, and MARS 200 - is a Security Threat Mitigation (STM) appliance. 
It delivers a range of information about your networks’ health as seen through the “eyes” and “ears” of 
the reporting devices in your networks. It takes in all of the raw events from your reporting devices, 
sessionizes them across different devices, fires default rules for incidents, determines false positives, and 
delivers consolidated information through diagrams, charts, queries, reports, and rules. 


The MARS operates at distinct and separate levels based on how much information is provided about 
your networks’ devices. At its most basic level, MARS functions as a syslog server. As you add 
information about reporting devices, it starts sessionizing, and when fully enabled, it presents a 
bird’s-eye view of your networks with the ability to quickly drill-down to a specific MAC address. 


The MARS Web Interface 


wy 


The MARS user interface uses a tabbed, hyperlinked, browser-based interface. If you have used the Web, 
you have used similar Web pages. 


Note 


When using the MARS user interface, avoid using the Back and Forward arrows in the browser. Using 
these arrows can lead to unpredictable behavior. 
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About This Manual 


This manual describes the features and functionality of the Local Controller. The layout of this manual 
is as follows: 


Chapter 1, “STM Task Flow Overview,” recommends a taskflow for planning and implementing 
your security threat mitigation system. It ties back to your corporate security policies and presents 
a structure deployment and configuration strategy based on two phases: provisioning and 
monitoring. 


Part 1: Provisioning Phase. This part details provisioning your network devices to communicate with 
MARS. It involves performing device inventories, bootstrapping and configuring the reporting devices 
and mitigation devices to communicate with the MARS Appliance, and performing device-side tuning. 


Chapter 2, “Reporting and Mitigation Devices Overview,’discusses concepts important to a 
successful deployment of MARS. These concepts include selecting among the devices on your 
network, understanding the levels of operation, and performing those tasks that affect many devices, 
such as defining data pulling schedules. 


Chapter 3, “Configuring Router and Switch Devices.” 

Chapter 4, “Configuring Firewall Devices.” 

Chapter 5, “Configuring VPN Devices.” 

Chapter 6, “Configuring Network-based IDS and IPS Devices.” 
Chapter 7, “Configuring Host-Based IDS and IPS Devices.” 
Chapter 8, “Configuring Antivirus Devices.” 

Chapter 9, “Configuring Vulnerability Assessment Devices.” 
Chapter 10, “Configuring Generic, Solaris, Linux, and Windows Application Hosts.” 
Chapter 11, “Configuring Database Applications.” 

Chapter 12, “Configuring Web Server Devices.” 

Chapter 13, “Configuring Web Proxy Devices.” 

Chapter 14, “Configuring AAA Devices.” 

Chapter 15, “Configuring Custom Devices.” 


Part II: Monitoring Phase. This part concepts important to successfully using MARS to monitor your 
network. These concepts include defining inspection rules and investigating incidents. 


Chapter 16, “Policy Table Lookup on Cisco Security Manager” explains how to integrate with 
Cisco Security Manager and use the policy lookup features in MARS. 


Chapter 17, “Network Summary” covers the Summary pages which includes the Dashboard, the 
Network Status, and the My Reports pages. 


Chapter 18, “Case Management” covers using cases to provide accountability and improve 
workflow. 


Chapter 19, “Incident Investigation and Mitigation” covers incidents and false positives and 
provides a starting point for configuring a Layer 2 path and mitigation to work with a MARS. 


Chapter 20, “Queries and Reports” covers working with scheduled and on-demand reports and 
queries. It also discussing using the real-time event viewer. 


Chapter 21, “Rules” covers defining and use inspection rules. 
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e Chapter 22, “Sending Alerts and Incident Notifications” explains how to configure the MARS to 
send an alert based on an inspection rule. 


e Chapter 23, “Management Tab Overview” covers managing events, networks, variables, hosts, 
services, and MARS users. 


e Chapter 24, “System Maintenance” covers some of the maintenance chores for the MARS. 
Additionally, the following appendices are provided: 


e Appendix A, “Cisco Security MARS XML API Reference” presents the XML schema used by 
MARS for XML-based notifications. 


e Appendix B, “Regular Expression Reference” The syntax and semantics of the regular expressions 
supported by PCRE are described in this appendix. 


e Appendix C, “Date/Time Format Specfication” The date/time field parsing is supported using the 
Unix strptime() standard C library function. 


e Glossary — A glossary of terms as they relate to MARS. 


Obtaining Documentation 


Cisco.com 


Cisco documentation and additional literature are available on Cisco.com. Cisco also provides several 
ways to obtain technical assistance and other technical resources. These sections explain how to obtain 
technical information from Cisco Systems. 


You can access the most current Cisco documentation at this URL: 
http://www.cisco.com/univercd/home/home.htm 

You can access the Cisco webbiest at this URL: 
tap://www.cisco.com 

You can access international Cisco websites at this URL: 


http://www.cisco.com/public/countries_languages.shtml 


Documentation DVD 


Cisco documentation and additional literature are available in a Documentation DVD package, which 
may have shipped with your product. The Documentation DVD is updated regularly and may be more 
current than printed documentation. The Documentation DVD package is available as a single unit. 


Registered Cisco.com users (Cisco direct customers) can order a Cisco Documentation DVD (product 
number DOC-DOCDVD=) from the Ordering tool or Cisco Marketplace. 


Cisco Ordering tool: 
http://www.cisco.com/en/US/partner/ordering/ 
Cisco Marketplace: 


http://www.cisco.com/go/marketplace/ 
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Ordering Documentation 


You can find instructions for ordering documentation at this URL: 
http://www.cisco.com/univercd/cc/td/doc/es_inpck/pdi.htm 
You can order Cisco documentation in these ways: 


e Registered Cisco.com users (Cisco direct customers) can order Cisco product documentation from 
the Ordering tool: 


http://www.cisco.com/en/US/partner/ordering/ 


e Nonregistered Cisco.com users can order documentation through a local account representative by 
calling Cisco Systems Corporate Headquarters (California, USA) at 408 526-7208 or, elsewhere in 
North America, by calling 1 800 553-NETS (6387). 


Documentation Feedback 


You can send comments about technical documentation to bug-doc @cisco.com. 


You can submit comments by using the response card (if present) behind the front cover of your 
document or by writing to the following address: 


Cisco Systems 

Attn: Customer Document Ordering 
170 West Tasman Drive 

San Jose, CA 95134-9883 


We appreciate your comments. 


Cisco Product Security Overview 


Cisco provides a free online Security Vulnerability Policy portal at this URL: 
http://www.cisco.com/en/US/products/products_security_vulnerability_policy.html 
From this site, you can perform these tasks: 

e Report security vulnerabilities in Cisco products. 

e¢ Obtain assistance with security incidents that involve Cisco products. 

e Register to receive security information from Cisco. 
A current list of security advisories and notices for Cisco products is available at this URL: 
http://www.cisco.com/go/psirt 


If you prefer to see advisories and notices as they are updated in real time, you can access a Product 
Security Incident Response Team Really Simple Syndication (PSIRT RSS) feed from this URL: 


http://www.cisco.com/en/US/products/products_psirt_rss_feed.html 
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Reporting Security Problems in Cisco Products 


Cisco is committed to delivering secure products. We test our products internally before we release them, 
and we strive to correct all vulnerabilities quickly. If you think that you might have identified a 
vulnerability in a Cisco product, contact PSIRT: 


e Emergencies— security-alert@cisco.com 


e Nonemergencies—psirt @cisco.com 


Tip 


We encourage you to use Pretty Good Privacy (PGP) or a compatible product to encrypt any sensitive 
information that you send to Cisco. PSIRT can work from encrypted information that is compatible with 
PGP versions 2.x through 8.x. 


Never use a revoked or an expired encryption key. The correct public key to use in your correspondence 
with PSIRT is the one that has the most recent creation date in this public key server list: 


http://pgp.mit.edu: 1 1371/pks/lookup?search=psirt%40cisco.com&op=index&exact=on 


In an emergency, you can also reach PSIRT by telephone: 
e 1 877 228-7302 
e 1 408 525-6532 


Obtaining Technical Assistance 


For all customers, partners, resellers, and distributors who hold valid Cisco service contracts, Cisco 
Technical Support provides 24-hour-a-day, award-winning technical assistance. The Cisco Technical 
Support Website on Cisco.com features extensive online support resources. In addition, Cisco Technical 
Assistance Center (TAC) engineers provide telephone support. If you do not hold a valid Cisco service 
contract, contact your reseller. 


Cisco Technical Support Website 


wy 


The Cisco Technical Support Website provides online documents and tools for troubleshooting and 
resolving technical issues with Cisco products and technologies. The website is available 24 hours a day, 
365 days a year, at this URL: 


http://www.cisco.com/techsupport 


Access to all tools on the Cisco Technical Support Website requires a Cisco.com user ID and password. 
If you have a valid service contract but do not have a user ID or password, you can register at this URL: 


http://tools.cisco.com/RPF/register/register.do 


Note 


Use the Cisco Product Identification (CPI) tool to locate your product serial number before submitting 
a web or phone request for service. You can access the CPI tool from the Cisco Technical Support 
Website by clicking the Tools & Resources link under Documentation & Tools. Choose Cisco Product 
Identification Tool from the Alphabetical Index drop-down list, or click the Cisco Product 
Identification Tool link under Alerts & RMAs. The CPI tool offers three search options: by product ID 
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or model name; by tree view; or for certain products, by copying and pasting show command output. 
Search results show an illustration of your product with the serial number label location highlighted. 
Locate the serial number label on your product and record the information before placing a service call. 


Submitting a Service Request 


Using the online TAC Service Request Tool is the fastest way to open S3 and S4 service requests. (S3 
and S4 service requests are those in which your network is minimally impaired or for which you require 
product information.) After you describe your situation, the TAC Service Request Tool provides 
recommended solutions. If your issue is not resolved using the recommended resources, your service 
request is assigned to a Cisco TAC engineer. The TAC Service Request Tool is located at this URL: 


http://www.cisco.com/techsupport/servicerequest 


For S1 or S2 service requests or if you do not have Internet access, contact the Cisco TAC by telephone. 
(S1 or S2 service requests are those in which your production network is down or severely degraded.) 
Cisco TAC engineers are assigned immediately to S1 and S2 service requests to help keep your business 
operations running smoothly. 


To open a service request by telephone, use one of the following numbers: 


Asia-Pacific: +61 2 8446 7411 (Australia: 1 800 805 227) 
EMEA: +32 2 704 55 55 
USA: 1 800 553-2447 


For a complete list of Cisco TAC contacts, go to this URL: 


http://www.cisco.com/techsupport/contacts 


Definitions of Service Request Severity 


To ensure that all service requests are reported in a standard format, Cisco has established severity 
definitions. 


Severity 1 (S1)—Your network is “down,” or there is a critical impact to your business operations. You 
and Cisco will commit all necessary resources around the clock to resolve the situation. 


Severity 2 (S2)—Operation of an existing network is severely degraded, or significant aspects of your 
business operation are negatively affected by inadequate performance of Cisco products. You and Cisco 
will commit full-time resources during normal business hours to resolve the situation. 


Severity 3 (S3)—Operational performance of your network is impaired, but most business operations 
remain functional. You and Cisco will commit resources during normal business hours to restore service 
to satisfactory levels. 


Severity 4 (S4)—You require information or assistance with Cisco product capabilities, installation, or 
configuration. There is little or no effect on your business operations. 
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Obtaining Additional Publications and Information 


Information about Cisco products, technologies, and network solutions is available from various online 
and printed sources. 


Cisco Marketplace provides a variety of Cisco books, reference guides, and logo merchandise. Visit 
Cisco Marketplace, the company store, at this URL: 


http://www.cisco.com/go/marketplace/ 


Cisco Press publishes a wide range of general networking, training and certification titles. Both new 
and experienced users will benefit from these publications. For current Cisco Press titles and other 
information, go to Cisco Press at this URL: 


http://www.ciscopress.com 


Packet magazine is the Cisco Systems technical user magazine for maximizing Internet and 
networking investments. Each quarter, Packet delivers coverage of the latest industry trends, 
technology breakthroughs, and Cisco products and solutions, as well as network deployment and 
troubleshooting tips, configuration examples, customer case studies, certification and training 
information, and links to scores of in-depth online resources. You can access Packet magazine at 
this URL: 


http://www.cisco.com/packet 


iQ Magazine is the quarterly publication from Cisco Systems designed to help growing companies 
learn how they can use technology to increase revenue, streamline their business, and expand 
services. The publication identifies the challenges facing these companies and the technologies to 
help solve them, using real-world case studies and business strategies to help readers make sound 
technology investment decisions. You can access iQ Magazine at this URL: 


http://www.cisco.com/go/iqmagazine 


Internet Protocol Journal is a quarterly journal published by Cisco Systems for engineering 
professionals involved in designing, developing, and operating public and private internets and 
intranets. You can access the Internet Protocol Journal at this URL: 


http://www.cisco.com/ipj 


World-class networking training is available from Cisco. You can view current offerings at 
this URL: 


http://www.cisco.com/en/US/learning/index.htm] 
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STM Task Flow Overview 


This chapter describes the project phases and task flows that you should follow when you deploy MARS 
as a security threat mitigation (STM) system in your network. First, however, you must develop a set of 
policies that enables the application of security measures. 


Your security policy should: 


Identify security objectives for your organization. 
Document the resources to protect. 
Identify the network infrastructure with current maps and inventories. 


Identify the critical resources (such as research and development, finance, and human resources) 
that require extra protection. 


Your monitoring policy should: 


Identify the expected administrative traffic flows across your network, including user, source, 
destination, services, and hours of operation. 


Identify expected network traffic for security probing and vulnerability testing, including user, 
source, destination, services, and hours of operation. 


Identify the network infrastructure able to provide audit data in “network proximity” to the critical 
resources. 


Identify the various event logging levels available from the devices and hosts in the network 
infrastructure. 


Identify the devices and techniques used to investigate 


Your mitigation policy should: 


Identify the choke points on your network relative to the critical resources. 
Define your process for documenting mitigated attacks on layer 2 and layer 3 devices. 
Define your process for documenting mitigated attacks at the host and application layer. 


Resolve corporate ownership issues among network operations, security operations, host owners and 
application owners on shared hosts. 


Identify your policy for notifying security response teams and remediation teams. 


Identify vendor detection tool prioritization process, such as IOS IPS Dynamic Attack Mitigation 
(DAM). 


Identify how you want to block detected attacks: block them temporarily or permanently, block them 
using MARS-generated rules, using custom rules defined by security operations team, etc. 


Your remediation policy should: 
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e Identify the responses to detected but unmitigated attacks for each type of node in your network. 
e Identify tool vendor update policies to ensure proper remediation of hosts and applications. 


e Identify the policies and procedures for isolating infected legacy hosts where remediation options 
are unavailable. These procedures may include restoring from backups or network isolation. 


After you develop your policies, they become the hub of the Cisco Security Wheel, (Figure 1-1). 


Figure 1-1 Cisco Security Wheel 
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The spokes of the Cisco Security Wheel represent network security as a continual process consisting of 
four steps: 


1. Secure your system. 

2. Monitor the network for violations and attacks against your security policy and respond to them. 

3. Test the effectiveness of the security safeguards in place. 

4. Manage and improve corporate security. 

You should perform all four steps continually, and you should consider each of them when you create 

and update your corporate security policy. 

The remainder of this section details recommended task flows according to the following project phases: 
e Provisioning (see Checklist for Provisioning Phase, page 1-2). 
¢ Monitoring (see Checklist for Monitoring Phase, page 1-9). 


Check out http://www.cisco.com/web/about/security/intelligence/articles.html for more planning ideas. 
Look closely at the SAFE information. 


Checklist for Provisioning Phase 


Provisioning deals with planning, setting up and configuring the hardware, software, and networks that 
actually provide access to the data and network resources for the MARS Appliance. This phase takes 
place after you successfully complete the installation, which was detailed in the Install and Setup Guide 
for Cisco Security Monitoring, Analysis, and Response System. 


The following checklist describes the tasks required to understand the decision-making process and the 
basic flow required to provision MARS in the most productive manner. Each step might contain several 
substeps; the steps and substeps should be performed in order. The checklist contains references to the 
specific procedures used to perform each task. 
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Y_ |Task 


1. 


Inventory and review possible reporting devices, mitigation devices, and supporting devices. 


Reporting devices provide logs about user and network activities and device status and configuration. Mitigation 
devices can be used to respond to detected attacks. They also act as reporting devices. Supporting devices provide 
network services to reporting devices, mitigation devices, or a MARS Appliance. 


Identifying which devices on your network to monitor depends on multiple factors, including their placement, 
the reporting they can provide relative to other devices on the same network segment, and the level of operation 
that you want to achieve from your MARS Appliance. 


When considering which devices to declare as reporting devices and mitigation devices, be sure you know what 
data is provided to MARS by those devices. Simply adding all possible devices does not guarantee the best 
monitoring and mitigation strategy. Deliberate selection of the devices can reduce the MARS workload, resulting 
in improved detection and mitigation times, as well as improved false positive detection. 


Because MARS only considers monitored devices, you should take care in identifying which devices to monitor. 
The following are only a couple examples of considerations you should make when identifying devices. 


¢ Consider of the types of logs and data available from reporting devices on specific network segments, and 
select those logs that provide the most complete picture of the activity on your network. 


e Identify mitigation devices at natural chokepoints across each segment in your network. You are more likely 
to stop an attack if these mitigation devices are identified to MARS. When MARS identifies an attack, it 
studies the topology of your network to identify the best chokepoint; however, it only considers those devices 
that are monitored. 


Supporting devices can play an important role in the operation of your STM system. Therefore, you should 
inventory and review the supporting devices on your network, which include e-mail, AAA, DNS, and syslog 
servers, that will play a role in the envisioned STM system. 


Result: The list of devices that you want to monitor is complete. The details of each device include device name, 
reporting IP address, management IP address, management protocol, administrative account information, and the 
logging features, levels, and protocols to enable. 


For more information, see: 
e Selecting the Devices to Monitor, page 2-2 
e Levels of Operation, page 2-1 


e Deployment Planning Guidelines, page 2-1 in Install and Setup Guide for Cisco Security Monitoring, 
Analysis, and Response System 


e Device Inventory Worksheet, page 1-18 
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2. 


Tip 


Identify and enable all required traffic flows. 


After you identify the devices, you must verify that the network services they use for management, reporting, and 
notification are permitted along the required traffic flows. Using the detailed Device Inventory Worksheet 
identified in Step |., ensure that the management, logging, and notification traffic between the MARS Appliance 
and each supporting device, reporting device, and mitigation device is allowed by intermediate gateways. 


In addition, network services of supporting devices, such as DNS, e-mail, AAA, and NTP servers, must also be 
permitted to flow among the MARS Appliance, the supporting devices, and the reporting devices and mitigation 
devices on your network. 


MARS applies the device time to received events only. For all events pulled from devices such as IDS/IPS devices 
or Windows, MARS uses the reported time as long as that reported time falls within 3600 seconds of the time on 
the MARS Appliance. 


It is a recommended security practice to have all devices, including MARS Appliances, synchronized to the 
same time. Also, since the MARS Appliance is an HTTPS server, it uses certificates which require the time, 
date, and time zone to be set properly. Otherwise, sessions and incidents are stamped incorrectly and you may 
experience “time out” errors when accessing the web interface. 


To limit troubleshooting, you should test each traffic flow from the source network segment to the destination 
segment. If possible, you should test all device-to- device flows for each protocol to ensure that best match versus 
first match semantics of various gateway ACLs do not hinder required traffic flows. As with any security devices 
on your network, enabled traffic flows should be restricted to the required protocols, ports, and source/destination 
pairs. 


Result: You have verified that all intermediate gateways permit the log, management, and notification traffic 
between the devices and the MARS Appliance. 


For more information, see: 


e Event Timestamps and Processing in Top Issues for the Cisco Security Monitoring, Analysis, and Response 
System 


e Deployment Planning Guidelines, page 2-1, in Install and Setup Guide for Cisco Security Monitoring, 
Analysis, and Response System 


e Supporting Devices, page 2-1, in Install and Setup Guide for Cisco Security Monitoring, Analysis, and 
Response System 


¢ Required Traffic Flows, page 2-2, in Install and Setup Guide for Cisco Security Monitoring, Analysis, and 
Response System 


e Specify the Time Settings, page 5-10, in Install and Setup Guide for Cisco Security Monitoring, Analysis, 
and Response System 


e Device Inventory Worksheet, page 1-18 
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Q 3. Bootstrap the reporting devices, mitigation devices, and supporting devices. 


For each device identified in the Device Inventory Worksheet, you must prepare, or bootstrap, that device to 
ensure that the desired communications with MARS occur. Bootstrapping a device involves configuring the 
settings for that device, as determined by its role within the STM system. Perform the following bootstrap tasks 
as applicable to a device type and its role: 


e Enable management of the device by the MARS Appliance for mitigation and access. 

e Install an agent that collects the correct logs for MARS Appliance. 

e Turn on the correct logging level and logging services. 

e Direct the logs to the MARS Appliance or identify the appliance to receive or pull those logs as needed. 
e Enable discovery of the device settings. 

e Enable the device to receive notifications from the MARS Appliance. 


Each device has a different required configuration to ensure that it assumes the role you have envisioned for it in 
the STM system. As you consider the devices, their expected role in your STM system will correlate directly with 
the configuration of the tasks listed above. In addition, you identify any restrictions imposed by MARS. For 
example, MARS may restrict the supported protocols for discovery of a specific device type. 


Result: The correct logging levels are enabled on the reporting devices and mitigation devices. The MARS 
Appliance can receive or pull any necessary logs from those devices, and it can retrieve configuration settings 
and push ACLS to the supported mitigation devices. Any devices that require notification of detected attacks are 
configured to receive such notifications from the MARS Appliance. While the MARS Appliance picks up and 
stores the events it receives, it does not inspect them until the reporting devices and mitigation devices are defined 
and activated in web interface. 


Tip Any events published by a device to MARS prior to adding and activating the device in the web interface can 
be queried using the reporting IP address of the device as a match criterion. This technique can be useful for 
verifying that the device is properly bootstrapped. 


For more information, see: 
e¢ Device Inventory Worksheet, page 1-18 
e Supported Reporting and Mitigation Devices, page 2 
¢ Bootstrap Summary Table, page 2-12 


e The log settings sections of the user guides for your reporting devices and mitigation devices 
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4. 


Define the devices in MARS. 


After you identify and bootstrap the reporting devices and mitigation devices and enable the required traffic 
flows, you must represent those devices in MARS, which uses this information to communicate with the devices. 
You can do this by adding individual devices in the web interface or by importing a comma separated vector 
(CSV) file, which can define the required settings for basic device types and give you a headstart on defining the 
more complicated devices. In addition, you can use topology discovery to automatically discover reporting 
devices and mitigation devices and later go back to provide additional detail. 


For most device types, you must determine what access protocol to use for device discovery. The selection of this 
protocol determines what type of data you can discover and whether you can perform mitigation. Understanding 
the options helps you develop a consistent approach in compliance with your corporate policies. 


How you choose to add the devices depends on the number of devices on your network and whether there are 
CSV device keywords for the devices that you want to add. In addition, device types that use agents, modules, or 
sensors are defined in multiple steps, where you first define the base host or device, and then add the modules, 
sensors, and agents to the base device. For example, if you want to add an IPS module to a Cisco ASA device, 
you must first define the Cisco ASA device and then define the IPS module as a component of that device. In 
addition, many applications that are not dedicated appliances require that you first define the host (generic, 
Windows, Unix, or Linux) on which that application runs before you can associate the application with that host. 


After you add the devices, you must activate them by clicking Activate on any page in the web interface. 


To display all devices that are either added incorrectly or not activated in MARS, you can define one of two 
queries: 


e¢ Select “Unknown Reporting Device” in the Devices field. This query returns the events only for those devices 
that are reporting events that do not matching the one of the reporting IPs defined in MARS. When MARS 
receives events, it first determines if the IP from which the events are received matches one of reporting IPs 
identified in the Reporting and Monitor Devices page. Only if MARS finds a match does it attempt to parse 
the events. Therefore, if the Reporting IP is defined incorrectly for a reporting device, the events from that 
device are not parsed. This query essentially identifies events that are not parsed. 


e Select the “Unknown Device Event Type” in the Events field. This query returns events from known devices 
that for some reason the event is not parsed by MARS (for example, if the MARS signature list is not current 
with the device event lists), and it returns events reported by unknown devices. 


These queries are a recommended good practice after adding the devices, especially when using a CSV seedfile 
or SNMP discovery. For both queries, if you are looking for a specific reporting IP address, enter that address in 
the Keyword field to filter the results down to those that include that IP address. 


Result: All reporting devices and mitigation devices are defined and activated in MARS. When the devices are 
bootstrapped and defined in MARS, MARS begins to inspect the logs received from the devices. Until the devices 
are added in MARS, MARS picks up and stores the events it receives without inspecting them. 


For more information, see: 
e Device Inventory Worksheet, page 1-18 
e Selecting the Access Type, page 2-10 
e Add Reporting and Mitigation Devices Individually, page 2-17 
e Add Multiple Reporting and Mitigation Devices Using a Seed File, page 2-20 
e Adding Reporting and Mitigation Devices Using Automatic Topology Discovery, page 2-25 
e Supported Reporting and Mitigation Devices, page 2 (CSV Keyword column) 
e Verify Connectivity with the Reporting and Mitigation Devices, page 2-26 


e Activate the Reporting and Mitigation Devices, page 2-27 
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5. Configure global data collection settings and schedules in MARS. 


After you add the devices, you can enable the rich data collection features of MARS, which include: 


Dynamic vulnerability scanning. When MARS detects an attack, it can probe the network to determine the 
likely success and severity of the attack. To allow this data collection in response to detected attacks, you 
must enable the feature and identify which networks to analyze. 


NetFlow data collection. NetFlow data enables MARS to identify anomalies by profiling typical data flows 
across your network, allowing MARS to detect day-zero attacks, including worm outbreaks. Statistical 
profiling takes between four days and two weeks for a MARS Appliance to complete. When the profiles are 
developed, MARS begins detecting anomalous traffic flows and creates incidents in response to them. To 
configure NetFlow data collection, you must configure those devices that can generate NetFlow traffic, and 
you must configure MARS to listen on a shared community string. 


Layer 3 topology discovery. A process-intensive operation that discovers the layer 3 network devices (that 
is, those devices operating at the IP layer). This layer 3 data is used to determine the attack path vector and 
to populate the Topology graphs. You can define the schedule for updating this information. 


Layer 2 device discovery. This feature allows MARS to determine the attack path vector and to identify 
attacking hosts and targets by MAC address, which eliminates confusion caused by attacks that spoof IP 
addresses. This feature is typically configured when adding a switch and enabling mitigation. 


There are also several device types from which MARS periodically pulls data. For such devices, you can define 
the intervals at which the event logs are retrieved and processed. These update features are as follows: 


Distributed Threat Mitigation (DTM) device updates. The DTM services poll Cisco IPS and Cisco IDS 
devices to determine the top firing signatures across the reporting devices. Based on this information, MARS 
generates the list of top signatures that are firing on the network so that Cisco IOS Routers running the DTM 
feature set can query MARS for the list of signatures they should be running. 


Windows event logs. You can set the frequency by which MARS pulls audit trail records from Windows 
hosts and servers. This setting is global for all such hosts and has a default value of five minutes. 


Oracle event logs. You can set the frequency by which MARS pulls audit trail records from Oracle database 
servers. This setting is global for all such servers and has a default value of five minutes. 


Monitored device update scheduler. You can set the frequency by which MARS pulls data from specific 
reporting devices, such as Qualys QualysGuard, Foundstone Foundscan, and eEye REM. Schedules are set 
on a per IP address basis. 


After you define the settings, you must activate them by clicking Activate on any page in the web interface. 


Result: The schedules for updating cached data pulled from reporting, mitigation, and supporting devices are 
defined and activated in MARS. After these settings are defined, MARS can probe the network or pull updates 
from reporting, mitigation, and supporting devices. 


For more information, see: 


Data Enabling Features, page 2-28 

Windows Event Log Pulling Time Interval, page 10-10 
Layer 2 Discovery and Mitigation, page 2-29 

Configure Interval for Pulling Oracle Event Logs, page 11-3 
Networks for Dynamic Vulnerability Scanning, page 2-29 
Understanding NetFlow Anomaly Detection, page 2-30 
Configuring Layer 3 Topology Discovery, page 2-36 


Technology Preview: Configuring Distributed Threat Mitigation with Intrusion Prevention System in 
Cisco Security MARS, page 1 


Scheduling Topology Updates, page 2-39 User Guide for Cisco Security MARS Local Controller 
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6. Populate vulnerability assessment information for supporting devices and network assets. 


Vulnerability assessment information describes specific hosts on your network. You can detail this information 
for any host, whether it is a host representing a reporting device, a mitigation device, or an important asset on 
your network. 


This information identifies the operating system, patch levels, and the network services that run on the host. 
After you define the hosts, you must activate them by clicking Activate on any page in the web interface. 
Result: MARS understands more about the hosts on your network and the services that they run. 
For more information, see: 

¢ Host and Device Identification and Detail Strategies, page 2-36 

e Device Inventory Worksheet, page 1-18 

e IP Management, page 23-3 


e Service Management, page 23-7 
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Monitor and tune event generation and processing. 


As with all monitoring applications, tuning log generation and event processing is key to technical accuracy and 
performance. You can use two methods to tune which events are processed by MARS: 


Device-side tuning. This method involves restricting event generation at the device level. MARS never 
receives events that are not relevant to security or device status. It also involves eliminating superfluous, 
duplicate data reported by multiple devices on the network, as well as eliminating those events that can be 
reproduced by reports or queries in MARS, such as traffic summary syslogs. 


Appliance-side tuning. This method involves identifying events received by the MARS Appliance that 
represent normal or planned network activity. Drop rules are defined to prevent MARS from processing such 
events as part of potential security incidents. When defining such drop rules, you should be as precise in the 
definition as possible, for example, identify the source of expected ping sweeps by an IP address within an 
expected time period, which is much more difficult to spoof as it requires explicit knowledge of your network 
and administrative practices. You can further qualify the rules using a combination of seven conditions: 
source, destination, service type, event type, time range, reporting device, and event severity. You must 
choose whether to drop the event entirely or to drop it and log it to the database, where it can be used by 
queries and reports. 


Drop rules do not prevent MARS from storing the event data; they simply prevent the appliance from 
processing the events. Events affected by drop rules can still appear a query as they are being stored on the 
appliance. You are still storing them; just not processing them for inspection rules.Therefore, if appliance 
storage considerations are an issue, we recommend using device-side tuning. 


Tuning is an ongoing task to improve the identification of attacks, report quality surrounding truly suspicious 
activities, and the overall performance and accuracy of your STM solution. It involves a detailed study of traffic, 
which can be conducted and refined by evaluating the events that are coming into the appliance on a 
device-by-device basis. 


Y/Y |tTask 
7. 
| 
Note 
Tip 


In a lab network environment, use a MARS Appliance to study generated events and tuning options on an 
individual device type basis. By documenting your requirements in a controlled environment, you can 
eliminate much of the production network tuning by establishing valuable device-side tuning standards for 
each monitoring device type. 


Result: The events being processed by the MARS Appliance are restricted to those that provide value to the STM 
system. 


For more information, see: 


Appliance-side Tuning Guidelines, page 1-17 


Configuring Logging Policies on Firewall Devices in User Guide for Cisco Security Manager 3.0 


Checklist for Monitoring Phase 


After you complete the provisioning phase, you must configure MARS to help you realize your broader 
security goals and requirements. During the monitoring phase, your primary goal is to effectively realize 
your monitoring, mitigation, and remediation policies. This phase involves defining the strategies, rules, 
reports, and other settings required to achieve this goal. 


\ 


Note You must prepare MARS to closely adhere to your corporate security policy before you begin monitoring 


traffic flows, as you must be prepared to react to detected attacks. 
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The following checklist describes the tasks required to understand the decision-making process and the 
basic flow required to operate MARS in the most productive manner. Each step might contain several 
substeps; the steps and substeps should be performed in order. The checklist contains references to the 
specific procedures used to perform each task. 


Y/Y |tTask 


1. Develop monitoring, notification, mitigation, remediation, and audit strategies. 


These strategies are concerned less with desired traffic flows and generated events and focus more on what to do 
after MARS Appliance processes that data. These strategies are at the heart of how you will use MARS to protect 
your network, taking into account the short- and long-term requirements of monitoring and forensic analysis, as 
well as how to stop ongoing attacks and clean infected hosts. These strategies encompass not only your expected 
interaction with MARS, but the expectations of your reporting devices as well. Essentially, they identify the roles, 
tasks, and data requirements that you anticipate so that you can map events, rules, queries, and reports to those 
roles that provide the data required by the identified tasks. 


As with any security system, we recommend that users be assigned the lowest-level privilege required to perform 
their job. Admin-level privileges should be reserved for administrators of the MARS Appliance. 


Result: You have identified the users and roles required to effectively respond to detected attacks and device 
issues. You have defined clear guidance for responding to notifications and understand the information 
requirements of those such notifications and the expected format and delivery methods to be used. 


For more information, see: 
e Strategies for Monitoring, Notification, Mitigation, Remediation, and Audit, page 1-16 
e Case Management, page 18-Is 
e User Management, page 23-8 
e , page 23-13 
e User Role Worksheet, page 1-20 
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gQ 2. Define the notification services. 
This task prepares the notification services of MARS to notify your mitigation and remediation personnel and 
take other required actions. In MARS, notification services have three building blocks: 
¢ User accounts. Represent users who will receive reports or notifications or who will access the web interface 
for the purpose of monitoring or mitigation. Users can receive notifications in the form of e-mail, pager 
messages, or Short Message Service (SMS) messages. Users are assigned to one of four roles, admin, 
security analyst, operator, notification only, which determines their access privileges in the web interface. 
e Devices. Represent those devices that will receive notifications in the form of an SNMP message, a syslog 
message, or in the case of an IOS IPS device, a DAM message (equivalent to a shun). For more on defining 
devices, refer to Checklist for Provisioning Phase, page 1-2. 
¢ Actions. Actions are defined within inspection rules, and they represent the notifying action. Depending on 
the target of the notification, a user or a device, your action can provide guidance to your staff or instruct 
your devices to log or block an attack. 
Within MARS, any person or device that is expected to receive a notification must be identified in the system. 
Therefore, the first step is to define user accounts that map to the users or groups who must be notified based on 
specific event settings (see User Role Worksheet, page 1-20). You must also identify the devices that need to be 
notified or that need to take some action (see Device Inventory Worksheet, page 1-18). 
The next step is to define the notification service settings (actions), which can be one or more of e-mail, page, 
SMS, SNMP, Syslog, or Dynamic Attack Mitigation. Each of these settings includes the contact information and 
a message that you can define for each type of notification. 
There is not a separate interface for defining these settings. To define the notification service settings, you must 
edit an existing inspection rule and add new Action definitions. After you define these settings, they are available 
to all inspection rules. 
Result: All required personnel have been identified in MARS so that rules and reports can be customized to notify 
the correct personnel. 
For more information, see: 
e User Management, page 23-8 
e Add or Remove a User from a User Group, page 23-12 
e IP Management, page 23-3 
e Adding Reporting and Mitigation Devices, page 2-16 
e Forwarding Alert Data to 3rd-Party Syslog and SNMP Servers, page 2-43 
e MARS MIB Format, page 2-43 
e Inspection Rules, page 21-4 
e Working with System and User Inspection Rules, page 21-17 
e Setting Alerts, page 21-23 
e Sending Alerts and Incident Notifications, page 22-1 
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3. 


Define custom inspection rules and refine system inspection rules. 


Inspection rules correlate events from disparate devices into meaningful sessions that reflect the end-to-end 
activities of an attack or other network session. By identifying the end-to-end view of attacks, MARS is better 
able to identify mitigation points in your network. However, you can define inspection rules to accomplish 
different goals: identification of an attack is just one possible goal. Other example goals include identifying use 
of priority assets, network health, and refining your network configuration based on usage analysis. 


MARS ships with over 100 system inspection rules; however, you may find that you cannot identify those 
sessions that are important to your corporate policies. For example, if you want to monitor the use of a custom 
or unsupported application, you can either define a new inspection rule that monitors traffic between a selected 
source and destination using a known protocol and port pair, or define a custom log parser that uniquely processes 
the events generated by that application to expose the data within the event that you want to track. Monitoring a 
known protocol port pair can provide summary data, such as number of sessions, where a custom log parser can 
enable detailed inspection of aspects of the traffic, such as resource utilization or failed logging attempts. To 
define a custom parser, you must know the message format used by that appliance and it must be published to 
MARS in clear text. 


Organizing the rules that you create into meaningful groups can help clarify your purpose and improves the 
learnability of the system. As you consider your specific goals, you should define a rule group (and a 
corresponding report group) to help you refine the strategies you identified in Step 1. Because rules can be 
members of multiple groups, you do not have to worry about creating multiple rules to address the same issue. 
The groups are merely available to help your organize your work and allow you to focus on one strategy at a time. 


Result: Any custom inspection rules are developed and existing inspection rules are configured to provide proper 
notification in compliance with your corporate policies. Any custom log parser and inspection rules are defined 
that enable the audit of the traffic flows of home-grown or unsupported applications or protocols. 


For more information, see: 
e¢ Rule and Report Groups, page 21-24 
e Event Management, page 23-1 
e IP Management, page 23-3 
e Service Management, page 23-7 
e User Management, page 23-8 
e Adding User Defined Log Parser Templates, page 15-1 
e Inspection Rules, page 21-4 
e¢ Working with System and User Inspection Rules, page 21-17 
e Setting Alerts, page 21-23 
e Sending Alerts and Incident Notifications, page 22-1 
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4. 


Define custom queries and reports. 


Queries and reports are forensic analysis tools. They help you analyze historical data and enable you to identify 
trends over longer periods of time than the real-time monitoring features of MARS. The relationship between 
queries and reports is essentially that queries are on-demand, refined inspections of data as defined by a report 
template. Reports are scheduled to run periodically, enabling you to define the periods and frequencies that you 
want to inspect on an ongoing basis. Queries allow you to narrow or broaden your search based on a report 
template by filtering the search criteria. WhileMARS provides many predefined report templates, you can define 
new report templates that focus on the incidents and events important to fulfilling your policies. This feature can 
be especially useful for adhering to compliance reporting requirements, as you can define a report, schedule it to 
be generated, and store the results as part of your audit records. 


As with overall access, you can restrict the ability to run or view reports and queries based on user role. Such 
safeguards can reduce accidental tampering with schedule reports by other users of the system.In addition, you 
can configure your report templates so that users are notified of the report. Typically, e-mail is the primary 
method used for report notification, but all notification methods are supported. 


Result: The report templates required to realize your forensic analysis and audit goals are defined and assigned 
to user roles according to your least privilege policies. Any report groups that facilitate access or division of 
reports and queries among your staff are defined. 


For more information, see: 
¢ Queries and Reports, page 20-1 
¢ Queries, page 20-1 
e Perform a Batch Query, page 20-19 
e¢ Reports, page 20-22 
e Creating a Report, page 20-24 
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5. 


Monitor network and security activity. 


This task encompasses monitoring your network for attacks or issues and responding to them. How users interact 
with MARS depends on their role and your operational guidelines. For users who are expected to use the web 
interface to monitor traffic in near real-time, this task requires an in-depth understanding of the data that is 
correlated and displayed, as well as when and how to respond to suspicious or anomalous behavior. 


MARS provides two interfaces to network and security activity: the Summary tab and the Query/Reports tab. 
Each interface provides different views and tools to help you understand what is happening on your network. 


The Summary tab focuses on near real-time events, whereas the Query/Reports tab focuses on historical, forensic 
analysis as described in Step 4. The Summary tab organizes priority views of your network activity, displaying 
hot spot diagrams, recent events, charts of incidents, and a topology diagram, identifying recent activities. 


When you identify an incident that requires further investigation or mitigation, you can investigate the incident 
to determine whether it is a false positive or block attack using MARS. If you have choke points operating at layer 
2, primarily switches, MARS will identify the appropriate device, provide recommended CLI changes, and allow 
you to push these changes to the device. If the choke point is a layer 3 device, MARS recommends CLI changes 
that you can copy and paste into an administrative session with the identified choke point. 


In this manner, you can monitor your network for suspicious behavior and respond to any detections. 
Result: Users understand the views and tools required to monitor, verify, and mitigate attacks on the network. 
For more information, see: 

e Network Summary, page 17-1 

e Incident Investigation and Mitigation, page 19-1 

e False Positive Confirmation, page 19-6 

e Rule and Report Groups, page 21-24 

e Event Groups, page 23-2 

e Case Management, page 18-1 

e The False Positive Page, page 19-8 

e¢ Retrieving Raw Messages, page 24-3 
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6. Monitor system and network health. 

The STM system is more than your MARS Appliance; it includes all reporting devices and mitigation devices 
and any MARS Appliances. When assessing the health of the system, you should monitor the health of each of 
these devices. You can monitor your system health by using inspection rules that generate notifications for 
anomalous behavior, by generating system health queries and reports, and by manually reviewing the system logs 
of MARS. 

MARS provides reports about use of common resources, including CPU, bandwidth, and memory. To simplify 
the monitoring of system health, you can define a report group that organizes these reports into a meaningful 
collection. You can also restrict the presentation of those reports and queries to specific user roles. 

Because reports can be scheduled, you can notify the appropriate users each time the report is updated. 

Tip If you cannot view the resource usage of a reporting device, verify that you have enabled the Monitor 
Resource Usage option as part of that device definition in Admin > System Configuration > Security and 
Monitored Devices. For the list of devices that can be configured to provide this data, see Configuring 
Resource Usage Data, page 2-41. 

MARS also includes detailed logs about the status of the appliance itself, as well as several command-line 
utilities that present status on the health of the appliance. 
Result: The users responsible for monitoring the system and network health understand the tools and reports 
provided by MARS to perform these functions. 
For more information, see: 

e Rule and Report Groups, page 21-24 

e Rule and Report Group Overview, page 21-25 

e¢ Configuring Resource Usage Data, page 2-41 

e pnstatus, page A-22 

e pnlog, page A-18 

e Setting Runtime Logging Levels, page 24-1 

e Viewing the Appliance’s Log Files, page 24-2 

e Viewing the Audit Trail, page 24-3 

e Retrieving Raw Messages, page 24-3 
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7. Tune MARS processing. 


Tuning, which is an ongoing activity for any monitoring application, involves refining the sensitivity and 
accuracy of how events are processed. In MARS, you can do any of the following to effect such changes. 


Use drop rules to enable or disable the processing of events by MARS. 
Turn on or off event generation at the device. 
Identify selected incidents as false positives. 


Tune inspection rules to include or exclude specific networks, hosts, services, reporting devices, or traffic 
flows. 


Tune the inspection of traffic by device type, such as IPS and IDS, refining the rule set they use to generate 
events. 


Add or remove reporting devices to alter the reported event set or to provide supporting data that can be used 
to improve the self-tuning features of MARS, such as false positives, OS fingerprinting, and vulnerability 
assessment. 


Describe the expected behavior on your network by describing the assets, services, and vulnerability 
assessment information. The more details MARS knows about your network, the better it can assess the 
incoming events. 


Result: The events being processed by the MARS Appliance are restricted or expanded to encompass those that 
provide the most value to the STM system. 


For more information, see: 


Appliance-side Tuning Guidelines, page 1-17 
Working with Drop Rules, page 21-21 
False Positive Confirmation, page 19-6 


Selecting the Devices to Monitor, page 2-2 


Strategies for Monitoring, Notification, Mitigation, Remediation, 
and Audit 


STM requires the close coordination of multiple strategies in support of your corporate security policies: 


e Monitoring involves the study of network activities and device status to identify anomalous 
activities or behavior. 


e Notification involves alerting those parties responsible for responding to detected anomalies with 
the information necessary to respond. 


e Mitigation involves responding to suspicious activity to prevent the spread of anomalies across your 
network. 


e Remediation involves responding to successful exploits to clean infected hosts on your network. 


e Audit involves logging and reporting activities that have taken place during other tasks. The goal of 
audit is to provide an account the activities and responses to support compliance audits and trend 
analysis. 
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The first decision you must make is who will be responsible for mitigation at the selected choke points. 
Often, organizations separate specialized security devices from the core network infrastructure devices 
along organizational divisions. As an example, two separate teams, security operations and network 
operations, may be responsible for different network components or different policies on shared devices. 
Before you roll MARS out on your network, ownership of a strategies for mitigation must be clearly 
defined in according with your corporate policies. 


When it comes to a mitigation strategy, two options exist: 


e You can rely on MARS to identify the choke point and accept the recommended CLI changes to 
block the detected attack. 


e You can issue notifications and incident details to a responsible party who can evaluate the MARS 
recommendations, but ultimately that party will make the final decision about where and how to stop 
the detected attack. 


Regardless of the option you choose, you should develop guidelines on how long an attack should be 
blocked, how to investigate an internal attack so that you can clean them, who is responsible for updating 
the policies after the required quarantine period, and how records of such events should be maintained 
for audit compliance (for example, is the case management feature of MARS tied to your ticket 
integration system?). 


Next, you should make a distinction in the type of monitoring that you should perform: system 
monitoring versus security monitoring. System monitoring involves monitoring not only the status of the 
MARS Appliance but also the health and status of the reporting devices and mitigation devices that 
MARS manages. Security monitoring focuses on network and security activity. 


For both types of monitoring, you must decide what predefined and custom queries and reports are 
required, the processes for evaluating and responding to the data they reveal, and guidelines on using the 
case management features of MARS to manage the responses and track changes. 


The last phase involves determining who should be notified when specific incidents are detected. For 
example, who is notified of device status incidents versus security-related incidents. You must identify 
your mitigation and remediation personnel, identify those responsible for monitoring (across 
organizations if necessary), and determine how notifications are to be generated and what they should 
look like. This involves selecting among methods, including SMS, pager alert, and e-mail, as well as 
whether the notifications are based on incidents, queries, or reports. 


Appliance-side Tuning Guidelines 


Tuning on the MARS Appliance focuses on not inspecting traffic that is received from the reporting 
devices. Two primary techniques exist for appliance-side tuning: 


¢ Drop rules. This technique involves dropping all events that match specific criteria received from a 
reporting device. This technique is the fastest and the least refined. As part of defining a drop rule, 
you can also specify whether to retain the event log in or simply discard it. The advantage of drop 
rules is that they events are not processed by any inspection rules, which speeds up the processing 
of the appliance by reducing the potential workload. 


e Removing devices from inspection. This technique involves removing a device from inspection 
rules. This technique is specific to the events that trigger a specific type of alarm. The advantage of 
this technique is that is does not drop all events that match specific criteria received from a reporting 
device. In other words, your focus is on reducing a specific false positive rather than all incidents 
that are fired based on the events. In addition, the events are retained so that you can review them 
using queries and reports. 
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When using either of these techniques, remember that when you add or modify a rule, you must click 
Activate before the changes take effect. 


Device Inventory Worksheet 


The device inventory worksheet will help you collect the required information about the devices on your 
network. It includes the following information: 


Device name. Identifies the well-known name of the device. Typically, this name is the DNS name 
of the device. MARS uses this name in the topology graph, reports, and events. 


Reporting IP address. Identifies the IP address assigned to the network interface from which 
MARS will be receiving events. This address is used by MARS to map back to the device name and 
to uniquely identify messages and events originating from the device. 


Management IP address. Identifies the IP address assigned to the network interface to which 
MARS connects to discover the configuration settings for the device. 


Username/password. Identifies the account that has the correct authorization to connect to the 
management IP address and read or write information based on the role in the network. For reporting 
devices, this account must have privileges sufficient for MARS to read the existing configuration. 
For mitigation devices, specifically layer 2 switches, this account can enable MARS to publish 
actual CLI changes to the device to block detected attacks. 


Role in system/segment. Identifies whether this device is a reporting device or a mitigation device. 
It can also identify supporting devices, such as DNS and e-mail servers. In addition, the role should 
take into account this device’s expected importance relative to the network segment, specifically 
relative to the other devices on the same segment. You can qualify this segment-level role using 
terms that fit your overall monitoring strategy, such as primary source, second opinion, attack 
identification, false positive assessment, session data, and endpoint/MAC address identification. 
Understanding the role that a device can or should play at a network segment level helps prioritize 
the required and tunable log settings. 


Required protocols. Identifies the protocols that this device uses to operate. The primary focus is 
on the management protocols, notification protocols, and protocols used to publish audit events. 


Log settings/SNMP RO community string. Identifies the specific settings with respect to event 
and log generation that are required for this device to satisfy the role that it will play in the MARS 
system. It also identifies the SNMP RO community string for this device. 


Tunable. Identifies whether you can perform device-side tuning of the log generation. 
Notify. Identifies whether this device can receive notifications from MARS. 


Notification format. Identifies the format for any notifications that are sent to this device. 
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User Role Worksheet 


The user role worksheet will help you collect required information about administrators of your network. 
It includes the following information: 


User Name. Identifies the user by name. 
User Role. Identifies the role this user has with respect to your corporate security policies. 


MARS Account. Identifies the MARS user account and role—admin, security analyst, operator, or 
notification only—which determines access privileges in the web interface. For accountability and 
security, each user typically has a unique account. However, you can define group-based accounts. 


Notification Settings. Identifies the information required to contact this user when incident rules 
are fired. For users, notification settings include e-mail, pager messages, or SMS messages. For 
response teams, you may use group aliases. Users should be notified when inspection rules fire and 
scheduled reports are generated. 


Device Ownership. Identifies the reporting devices and mitigation devices on your network for 
which the user is responsible. This list is especially important when the user is a member of your 
mitigation or remediation team. 


Inspection Rules. Identifies any inspection rules required to meet the needs of this user role. These 
rules must to be defined or configured to notify the user when they fire. 


Reports/Queries. Identifies any reports and queries required to meet the needs of this user role. You 
must ensure that the user can access these reports and queries. Optionally, you may want to notify 
the user when scheduled reports are generated. 
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Table 1-2 User Role Worksheet 
MARS Notification Device 
User Name User Role Account/Role {Settings Ownership Inspection Rules |Reports/Queries 
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Reporting and Mitigation Devices Overview 


After you complete the initial configuration of Local Controller as described in Install and Setup Guide 
for Cisco Security Monitoring, Analysis, and Response System, you must determine a monitoring 
strategy to use for your network. You must also determine a mitigation strategy, if you chose to take 
advantage of the MARS mitigation features. For guidance on how to determine the monitoring and 
mitigation strategies, see STM Task Flow Overview, page I|-1. 


This chapters assumes that you have made corporate-level policy decisions and that you are executing 
against the Checklist for Provisioning Phase, page 1-2. This chapter provides the following: 


Guidance on selecting and configuring reporting devices and mitigation devices 
Discussion of the levels of operation that MARS supports 
Guidance on selecting a method for adding devices to Local Controller 


Discussion of those features that enable rich data collection 


It contains the following sections: 


Levels of Operation, page 2-1 

Selecting the Devices to Monitor, page 2-2 

Understanding Access IP, Reporting IP, and Interface Settings, page 2-8 
Selecting the Access Type, page 2-10 

Bootstrap Summary Table, page 2-12 

Adding Reporting and Mitigation Devices, page 2-16 

Data Enabling Features, page 2-28 


Integrating MARS with 3rd-Party Applications, page 2-43 


Before configuring the MARS Appliance to recognize reporting devices, you should understand the 
three levels of operation that MARS can achieve. 


Levels of Operation 


MARS operates at three discernible levels based on the type of data collected from reporting devices and 
the features such data enables for the system.These levels focus on the ability to identify attacks from 
end-to-end, and they are separate from the features enabled by specific types of reporting devices. 


Basic. At this level, MARS behaves like a smart syslog server. It collects reporting device logs and 
support basic queries and reports. To enable basic operation, you must complete the initial 
configuration of the MARS Appliance as described in Install and Setup Guide for Cisco Security 
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Monitoring, Analysis, and Response System. In addition, you must specify the device name and 
reporting IP addresses of the reporting devices as described in Adding Reporting and Mitigation 
Devices, page 2-16. 


e Intermediate. At this level, MARS processes events and performs session-based correlation, 
including resolving NAT and PAT translations at the IP address layer. To enable intermediate 
operation, you must provide more details about the devices you want to monitor, including access 
IP addresses, management access passwords, OS platforms and versions, and running services and 
applications, see IP Management, page 23-3 for more information. 


e Advanced. This level is a fully enabled MARS Appliance. When advanced operation is enabled, 
MARS Appliance discovers and displays the full topology, draws attack paths, and enables MAC 
address lookups of the hosts involved in an attack. To enable advanced operation, you must provide 
the SNMP community string information for your network. You must also enable topology 
discovery, as defined in Scheduling Topology Updates, page 2-39. 


Table 2-1 summarizes the levels, their configuration requirements, and the features enabled at that level. 


Table 2-1 Levels of Operation 
Level Of Operation Configuration Requirements Functionality Enabled 
Level 1 MARS configured Basic syslog functionality 
Reporting device names and reporting IP Event correlation 
addresses added Query, reports, and chart support 
Erno enabled NetFlow anomaly detection 
Level 2 Access IP addresses and information added Starts performing event and session-based 
correlation 
NAT and PAT resolution 
IP address lookup of attackers and targets 
Level 3 Community strings and networks added MAC address lookup of attackers and targets 


Topologies enabled 


Selecting the Devices to Monitor 


All monitoring strategies involve selecting the types of devices to monitor and how much data to provide 
the MARS Appliance. All devices on your network, be they hosts, gateways, security devices, or servers, 
provide some level of data that MARS can use to improve the accuracy of security incident 
identification. However, careful consideration of what data to provide can improve the attack 
identification response time by ensuring that MARS does not perform necessary or redundant event 
correlation and analysis. Unnecessary logging and reporting by reporting devices can also reduce the 
effectiveness of your network. 


We recommend analyzing each network segment to identify the most data rich combination that you can 
achieve, while identifying and refining your configurations to reduce redundant data. 


When determining a monitoring strategy, you must also determine the goals behind the monitoring. Is it 
just for attack detection? Attack detection and mitigation? Regulatory compliance? Your goals affect 
which devices you must monitor and what features you must configure on those devices. 


Consider distinct goals: 


e Attack detection 
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e Attack detection and mitigation 
e Regulatory compliance 
e Full NAC awareness 


e Identify the devices/feature pairs that overlap on the same network segment, where a choice between 
device can reduce duplicity or prioritize device performance 


Last, you must consider an event tuning method for your monitoring strategy. How you tune your MARS 
affects your overall operational costs proportionally to the number of device of a give type that are 
monitored. Essentially, if you have the bandwidth available, we recommend that you tune the events at 
the MARS Appliance, which reduces your operational costs by tuning at a single point in the network. 
However, if bandwidth is a precious commodity, you may chose to tune the event propagation at the 
reporting device level, preventing the events from going onto the network. 


Table 2-2 identifies the device types, describes what information they can provide, and recommends how 
to configure these devices within your network. 
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Table 2-2 Device Types and Data Available 
Device Type Data Available Recommended Configurations 
Router The device discovery protocol is the one used for |Enable the following: 


administrative access/mitigation. For example, if 
SSH is used to discover the device, then SSH is 
the protocol that used to pushed the mitigation ° Syslog traffic 


¢ SNMP RO community strings 


command. ¢ Device discovery via SSH or Telnet access 
The following data is pulled from routers: 


e hostname 

e static routes 

e ACL rules 

e static NAT rules 

e traffic flows 

¢ SNMP RO Community strings 
e NetFlow data 


e device status and resource utilization, such as 
memory, CPU, and interface/port statistics. 


e ARP cache table. Used to map IP address to 
MAC address. 


Switch During investigation and mitigation, the ARP Enable the following: 
cache tables are reviewed to resolve the MAC 
addresses involved in the incident. This data is 


e SNMP RO community strings 


cached for 6 hours. e Syslog traffic 

SNMP RO Community strings ¢ Device discovery via SSH or Telnet access 
Forwarding tables, used to map IP address to ¢ Enable NetFlow data 

MAC address. e Administrative access for mitigation push 


Device status and resource utilization, such as 
memory, CPU, and interface/port statistics. 


NetFlow data 


802.1x logs generated during NAC sessions 
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Table 2-2 Device Types and Data Available (continued) 
Device Type Data Available Recommended Configurations 
Firewall Interface configurations. Used to populate Enable the following: 


topology view and determine expected routes, 
which helps refine correlation of traffic traversing 
the firewall. 


NAT and PAT mappings. Used to identify the ° Device discovery 
point of origin attackers and targets and trace 
attacks as they spread. 


e SNMP RO community strings 


e Syslog messages 


Firewall policies. When discovering ASA, PIX, 
and FWSM, MARS parses ACLs and conduits 
(PIX only). For Check Point firewalls, it collects 
the firewall policy from policy table. 


MARS using this information only for path 
computation and mitigation recommendations. It 
is not used by any other components, such as 
rules, reports, and sessionization. 


Firewall logs. Accepted and denied sessions logs 
are used to identify false positives and determine 
if potential attacks were blocked before reaching 
their targets. 


Audit logs. Associates users with authentication 
sessions and assists in identifying exploited 
accounts and administrative sessions. 


ARP cache tables. Used to map IP address to 
MAC address. 


Device status and resource utilization 
information. Used to identify anomalous 
network activities based on memory, CPU, and 
interface and port statistics. 


VPN Remote user information. Provides username to 
IP address mapping. VPN client helps determine 
the person who logged in and performed specific 
actions. Clarifies the true point of origin by 
identifying the host, not the VPN concentrator. 


Login/logout records. Helps identifies worms by 
tracing outbreaks back to a specific user and 
provides network access periods. 


Device status information. Identifies whether 
the device is operational, which allows prediction 
of possible spread of potential attacks and worms. 


e SNMP RO Community strings 
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Table 2-2 


Device Type 


Device Types and Data Available (continued) 


Data Available 


Recommended Configurations 


Network IDS/IPS 


Fired signature alerts. Identifies attacks and 
threats, which helps determine mitigation 
response, identify potential false positive 
information, and target vulnerability assessment 
probes conducted by MARS. 


Trigger packet information. Provides the 
payload of the packet that caused the signature to 
fire. 


Determine whether an attack was blocked at a 
specific device. 


Device status information 


Host IDSes 


Provides host-level validation of exploits and 
blocked attacks, which improves the accuracy of 
false positive identification, which in turn 
improves the ability of the administrator to 
accurately prioritize the work required to contain 
attacks. 


Anti-Virus 


Central anti-virus management servers provide 
information on which hosts are infected, which 
hosts have reported attempted infections, etc. The 
servers also provide the dat or signature file 
information for managed hosts, which improves 
the ability to determine whether an attack was 
likely to have succeeded. 


Vulnerability 
Assessment 


Host OS and Patch Level. When a signature fires 
on an IDS and it is reported to MARS, MARS can 
either launch a targeted scan using Nessus, or 
query a vulnerability assessment system that 
helps determine whether the target was 
vulnerable. 


Enable any vulnerability assessment solutions 
supported by MARS. 
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Table 2-2 Device Types and Data Available (continued) 
Device Type Data Available Recommended Configurations 
Host OSes Microsoft Windows Hosts Install and configure SNARE, which pushes 


events to MARS in near real time, and scales more 


Events found in the security event log as well me . 
efficiently than pulling events from hosts. 


application event and system event log. 


Solaris and Linux Hosts e Enable logging for the xferlog and inetd 


Incoming network session logs, via inted, and applications: 


FTP transfer logs, via xferlog. In addition, any e Enable syslog daemon. 
events that are written to the system log by 


os : . e Identify the MARS Appliance as syslog 
applications and services running on host. 


target. 


Generic Hosts (All OSes) 


Includes system-level information, such as 
privilege escalation and buffer overflow. Helps 
determine what attacks make it to the host layer. 
If MARS learns of activity at the host level, then 
it understands that the attack or exploit has 
successfully traversed the network. MARS 
correlates this data with the network level data to 
discover the whole incident and analyze the 
exploit method so the administrator can build a 
better defense. In some cases, MARS 
recommends actions for mitigating the attack. We 
recommend that you maintain these 
recommended blocks as long as similar attacks 
are expected. Typical blocking techniques, such 
as IPS shunning, often fail to identify the best 
chokepoint for containment. As part of the 
recommended action, MARS does identify the 
optimal chokepoint where the recommended 
action should be effected. 


Web Server Same as hosts (SNARE and Perl script agents) 
need this when the hosts cannot send us the logs 
via syslog. agent is basically a transport. 


Web Proxy Mapping from user to site, translations for the IP 
address mapping, tells us the real address of the 
host who is likely infected. URLs and also 
filtering...regulatory compliance. 


Database Login/logout to determine the actual user (query 
report tab on the data). Privilege escalation, brute 
force crack type stuff, or maybe we want to do 
regulatory compliance. 
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Table 2-2 Device Types and Data Available (continued) 
Device Type Data Available Recommended Configurations 
AAA Server Login/logout and NAC functionality (deny a Supporting Cisco Secure ACS Server, page 14-2 


person due to privileges, it triggers NAC message) 
e passed authentication log 
e failed attempts log 


e RADIUS accounting log, including those 
events specific to NAC. 


Supporting Cisco Secure ACS Solution Engine, 
page 14-2 


Generic Syslog 


Same as host, provides support for additional 
customer devices. 


Generic SNMP 


Same as host, provides support for additional 
customer devices. 


Cisco Security Mana 
ger 


Mapping to any committed policy rules defined in 
Security Manager that match any ACL rules that 
could cause the generation of a specific syslog 
event by a reporting device. This policy lookup 
feature allows you to debug network issues and 
understand the cause/effect relationships between 
event messages and the device policies and traffic 
that resulted in the generation of the event. 


Enable HTTPS on the Security Manager server. 


Define an administrative level account on the 
Security Manager server that CS-MARS can use 
for policy lookups. 


Understanding Access IP, Reporting IP, and Interface Settings 


When defining a reporting or mitigation device in the web interface, MARS allows (and at times, 
requires) you to specify several IP addresses. Understanding the purpose of the different addresses is 
important to effectively defining the devices that you want to monitor and manage. It is also important 
to understand their relationship to other settings that you can identify. 


If a device has a single interface and a single IP address associated with that interface, the access and 
reporting IP addresses are the same as the address assigned to the interface. MARS collects this 
information separately to support those devices that have multiple interfaces, multiple IP addresses 


associated with a single interface, or both. 


Note 


Not all reporting devices support both an access and reporting IP address. Some devices use only access 
IP addresses to query the device for the required information (e.g., QualysGuard security service), while 
others have no settings that MARS can discover and only generate event messages for MARS to process 
(e.g., NetCache appliances). In addition, not all devices require the definition of interfaces. 


This section discusses the following three addresses and their relationship to other settings: 


e Access IP, page 2-9 
e Reporting IP, page 2-9 
e Interface Settings, page 2-10 
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Understanding Access IP, Reporting IP, and Interface Settings [i 


MARS uses the access IP address to either connect to the device for network-based administrative 
sessions or connect to a remote server on which a file containing the device’s configuration is stored. 
The expected value is determined by the access type you select. Most devices also require that you 
explicitly identify the IP addresses of hosts allowed to administer them. The MARS Appliance must be 
listed among such hosts as part of the device preparation. 


The protocol that MARS uses to connect to the device is defined by the access type value, which is a 
dependency for enabling administrative access. Once MARS has administrative access, it can perform 
device discovery, which includes settings such as ARP tables, NAT, routes, and active ACLs, all of which 
helps MARS understand the topology, perform attack path analysis, and identify false positive incidents. 
Discovery can be performed to varying degrees using any of the access types. For more information on 
access types, see Selecting the Access Type, page 2-10. 


MARS also uses SNMP RO and SNMPwalk to discover the device settings and topology information. 
However, the two methods of discovery are distinct and have distinct requirements. SNMPwalk requires 
the access IP address and the SNMP access type. SNMP RO discovery does not requires the SNMP 
access type, but it does require the access IP address. 


Note 


Reporting IP 


MARS does not support the following characters in the SNMP RO community string: ' (single quote), " 
(double quote), < (less than symbol), and > (greater than symbol). 


In addition, both SNMPwalk and SNMP RO are unrelated to SNMP notifications or SNMP traps. 
SNMPwalk and SNMP RO both require that MARS initiate the information request, where as SNMP 
notifications are event notifications published by the reporting device, much the same as syslog 
messages are. As with syslog messages, SNMP notifications are published over the reporting IP address. 


The reporting IP is the source IP address of event messages, logs, notifications, or traps that originate 
from the device. MARS uses this address to associate received messages with the correct device. For 
single-homed devices, the reporting IP address is the same as the access IP; for dual- or multi-homed 
devices, this address must be explicitly associated with the syslog, NetFlow, and SNMP services running 
on the reporting device. Most devices also require, for each message type, that you explicitly identify 
the IP addresses of hosts to which messages should be published. These hosts are commonly referred to 
as target log servers. The MARS Appliance must be listed among such hosts as part of the device 
preparation. 


The role in MARS of the reporting IP address differs from that of the access IP address in that the 
reporting IP address is treated passively from the MARS perspective. MARS does not query the device 
using this address. Such operations are performed using the access IP address and the access type. 


MARS accepts only one reporting IP address per device. For devices supporting two message formats, 
such as NetFlow and syslog, you must ensure that both message formats are bound to the same source 
IP address (the reporting IP). In Cisco IOS devices, this common association is not the default so you 
must change either the syslog or the NetFlow reporting IP address to match the other. If the message 
types do not originate from a common IP address, one of them is seen as originating from an unreported 
device and MARS does not parse those events correctly. 
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The supported format of event data varies among reporting devices. Just because the device is able to 
generate syslog, NetFlow, and SNMP notifications does not mean that MARS processes all three 
formats. The document, Supported Devices and Software Versions for Cisco Security MARS Local 
Controller 4.2.x, identifies the event retrieval protocol supported by each device type. 


Interface Settings 


Interface settings are exclusive to hosts and software applications running on hosts. While MARS can 
discover the settings of a reporting device that is a software application running on a host, it cannot 
discover settings about the host itself. The role of interface settings in MARS is different from that the 
access IP address and reporting IP address. Interface settings represent static information, not discovered 
or learned, about the host. 


When correlating events specific to a host or reporting devices running on that host, MARS needs to 
understand the number of interfaces installed in the host, their names, and the IP addresses and networks 
associated with them. MARS uses the interface settings to guide discovery operations, to determine 
attack path vectors, and to perform Nessus vulnerability assessments. 


Selecting the Access Type 


The access type refers to the administrative protocol that MARS uses to access a reporting device or 
mitigation device. For most devices monitored by MARS, you can choose from among four 
administrative access protocols: 


e SNMP. SNMP access provides administrative access to the device using a secured connection. It 
allows for the discovery of the settings using SNMPwalk, such as routes, connected networks, ARP 
tables, and address translations. If granted read-write access, SNMP also allows for mitigation on 
any L2 devices that support MIB2. 


e Telnet. Telnet provides full administrative access to the device using an unsecured connection. It 
allows for the discovery of the settings, such as routes, connected networks, ARP tables, and address 
translations. It also allows for mitigation on L2 devices. 


e SSH. SSH provides full administrative access to the device using a secured connection. It allows for 
the discovery of the settings, such as routes, connected networks, ARP tables, and address 
translations. It also allows for mitigation on L2 devices. This access method is recommended for 
DTM support; however, Telnet access can achieve the same results. 


e FTP. FTP passive discovery of settings by providing MARS access to a file copy of the 
configuration running on the router. FTP does not support mitigation, DTM, or discovery of 
dynamic settings, such as NAT and ARP tables. In addition, if you select the FTP access type for 
device types, such as Cisco ASA and FWSM, you can only discover settings for the admin context. 
This access method is the least preferred and most limited access method. To enable configuration 
discovery using FTP access, you must place a copy the device’s configuration file on an FTP server 
to which the MARS Appliance has access. This FTP server must have users authentication enabled. 


wy 


Note TFTP is not supported. You must use an FTP server. 


You can use any access scheme in conjunction with an SNMP RO community string. The division 
between Access IP and Reporting IP is clearly illustrated by an FTP access type example. Assume that 
you have SNMP RO access to a router, but your configuration discovery (access type) is restricted to a 
file stored on an FTP server. 
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When you define a device in MARS, the Access IP is the IP address of the FTP server (not the router), 
and the authentication information is used to access the FTP server. The Access Method is set to FTP. 
The Reporting IP is the IP address of the interface over which SNMP traps are published by the router. 


The following topics describe how to configure each access type, identifying the fields that should be 
completed when a specific access type is selected. For efficiencies sake, these procedures are referenced 
throughout the specific device configuration topics, as they related to a specific device type. 


e Configure SNMP Access for Devices in MARS, page 2-11 
e Configure Telnet Access for Devices in MARS, page 2-11 
e Configure SSH Access for Devices in MARS, page 2-12 
e Configure FTP Access for Devices in MARS, page 2-12 


Configure SNMP Access for Devices in MARS 


& 


This procedure assumes you are defining a reporting device or mitigation device and that you were 
referred to this procedure after selecting SNMP in the Access Type list. To select SNMP as the access 
type, you must provide MARS with SNMP read-write access. 


Note 


Step 1 


Step 2 
Step 3 


The SNMP access type is not required to enable the SMPO RO strings. In fact, no access type is required 
to support SNMP RO. SNMP RO uses a shared, read-only community string; it does not require a 
read-write community string as does the SNMP access type. 


If you selected SNMP as the access type, follow these steps: 


In the Login field, enter the username of the administrative account to use when accessing the reporting 
device. 


In the Password field, enter the password associated with the username specified in the Login field. 


If this device supports an enable mode, enter that password in the Enable Password field. 


Configure Telnet Access for Devices in MARS 


Step 1 


Step 2 
Step 3 


This procedure assumes you are defining a reporting device or mitigation device and that you were 
referred to this procedure after selecting TELNET in the Access Type list. 


If you selected TELNET as the access type, follow these steps: 


In the Login field, enter the username of the administrative account to use when accessing the reporting 
device. 


In the Password field, enter the password associated with the username specified in the Login field. 


If this device supports an enable mode, enter that password in the Enable Password field. 
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Configure SSH Access for Devices in MARS 


Step 1 


Step 2 


Step 3 
Step 4 


This procedure assumes you are defining a reporting device or mitigation device and that you were 
referred to this procedure after selecting SSH in the Access Type list. 


If you selected SSH as the access type, follow these steps: 


From the list box to the right of the Access Type list, select 3DES, DES, or BlowFish as the encryption 
cipher for SSH sessions between the MARS Appliance and the reporting device. 


In the Login field, enter the username of the administrative account to use when accessing the reporting 
device. 


In the Password field, enter the password associated with the username specified in the Login field. 


If this device supports an enable mode, enter that password in the Enable Password field. 


Configure FTP Access for Devices in MARS 


Step 1 
Step 2 
Step 3 


Step 4 


wy 


This procedure assumes you are defining a reporting device or mitigation device and that you were 
referred to this procedure after selecting FTP in the Access Type list. 


If you selected FTP as the access type, follow these steps: 


In the Login field, enter the username of the FTP server account to use when accessing the configuration 
file of the reporting device. 


In the Password field, enter the password associated with the username specified in the Login field. 


In the Config Path field, enter the path to the reporting device’s configuration file residing on the FTP 
server. 


This path begins at the root of the FTP server’s published folder, not at the root directory of server. 


In the File Name field, enter the name of the reporting device’s configuration file residing on the FTP 
server. 


Note 


If you select FTP, you cannot enter an enable password. 


Bootstrap Summary Table 


Table 2-3 summaries the settings that you must configure for reporting devices and mitigation devices. 
It also provides links to any required agent downloads and to detailed configuration information. 
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Device Type/Name 


Reporting and Mitigation Device Bootstrap Summary 


Bootstrap Summary 


Bootstrap Summary Table 


Reference Information 


Router/Switch 
Cisco Router 1. Access to IP address/interface by MARS. Cisco Router Devices, page 3-1 
Cisco Switch (IOS) 2. FTP, SNMP, Telnet or SSH access by MARS. |Cisco Switch Devices, page 3-9 
Cisco Switch (CatOS) | 3. Define SNMP RO community string. 
4. Turn on syslog, define log level, and define 
MARS as target of syslog messages. 
5. Enable NAC features. 
Extreme ExtremeWare | 1. Access to IP address/interface by MARS. Extreme Extreme Ware 6.x, page 3-17 
Generic Router 2. (ExtremeWare only) Turn on syslog, define |Generic Router Device, page 3-18 
log level, and define MARS as target of syslog 
messages. 
3. SNMP access by MARS. 
4. Define SNMP RO community string. 
Firewall Devices 
Cisco PIX 1. Access to access and reporting IP Bootstrap the Cisco Firewall Device, page 4-2 
Cisco Adaptive Security address/interface by MARS. 
Appliance (ASA) 2. FTP, Telnet, or SSH access by MARS. 
Cisco Firewall Services | 3. Define SNMP RO community string. 
Moe aN) Note SNMP settings should be defined for the 
admin context on ASA and FWSM. You 
do not need to define these settings for 
each security context. 
4. Turn on syslog, define log level, and define 
MARS as target of syslog messages. 
Cisco IOS Firewall 
Feature Set 
Juniper Netscreen NetScreen ScreenOS Devices, page 4-11 
Checkpoint Opsec NG | 1. Add the MARS Appliance as a host. Bootstrap the Check Point Devices, page 4-22 
awe) 2. Create and install an OPSEC Application 
Nokia Firewall (running object for the defined host. 
Checkpomy 3. Define policies to permit SIC traffic between 
the MARS Appliance, the Check Point 
management server, and any remote servers. 
4. Define the log settings to push the correct 
events to the defined host. 
5. Install the policies. 
VPN Devices 
Cisco VPN Cisco VPN 3000 Concentrator, page 5-1 
Concentrator 
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Reporting and Mitigation Device Bootstrap Summary (continued) 


Reference Information 


Device Type/Name 


Bootstrap Summary 


Network IDS 
Cisco Network IDS 1. Enable RDEP for IDS modules. Cisco IDS 3.1 Sensors, page 6-1 
Cisco IDSM 2. Configure the following signature actions: Cisco IDS 4.0 and IPS 5.x Sensors, page 6-5 


e Alert 


¢ (Optional) To view trigger packets, enable the 
“produce-verbose-alert”’. 


¢ (Optional) To view IP logs, enable the alert or 
“produce-verbose-alert” and 
“log-pair-packets”’. 


Cisco Intrusion 
Prevention System 
(IPS), Network IPS 


1. Enable SDEE for IPS modules. 
2. Configure the following signature actions: 
e Alert 


¢ (Optional) To view trigger packets, enable the 
“produce-verbose-alert”’. 


¢ (Optional) To view IP logs, enable the alert or 
“produce-verbose-alert” and 
“log-pair-packets”’. 


Cisco IDS 4.0 and IPS 5.x Sensors, page 6-5 


Cisco IPS ASA module 


1. Enable SDEE for IPS modules. 
2. Configure the following signature actions: 
e Alert 


¢ (Optional) To view trigger packets, enable the 
“produce-verbose-alert”’. 


¢ (Optional) To view IP logs, enable the alert or 
“produce-verbose-alert” and 
“log-pair-packets”’. 


Cisco IPS Modules, page 6-9 


Cisco IOS IPS module 


1. Enable SDEE for IPS modules. 
2. Configure the following signature actions: 
e Alert 


¢ (Optional) To view trigger packets, enable the 
“produce-verbose-alert”’. 


¢ (Optional) To view IP logs, enable the alert or 
“produce-verbose-alert” and 
“log-pair-packets”’. 


Cisco IPS Modules, page 6-9 


McAfee Intrushield 


IntruVert IntruShield, page 6-22 


Juniper Netscreen IDP 


NetScreen IDP 2.1, page 6-31 


Symantec Manhunt 


Symantec ManHunt, page 6-29 


ISS RealSecure 


ISS RealSecure 6.5 and 7.0, page 6-17 


Snort 


Snort 2.0, page 6-28 


Enterasys Dragon 


Enterasys Dragon 6.x, page 6-33 
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Table 2-3 


Bootstrap Summary Table 


Reporting and Mitigation Device Bootstrap Summary (continued) 


Reference Information 


Device Type/Name 


Bootstrap Summary 


Host IDS 


Cisco Security Agent 


Cisco Security Agent 4.x Device, page 7-5 


McAfee Entercept 


Entercept Entercept 2.5 and 4.0, page 7-1 


ISS RealSecure Host 
Sensor 


ISS RealSecure 6.5 and 7.0, page 6-17 


Anti-virus 


Symantec AntiVirus 


Symantec AntiVirus Configuration, page 8-1 


Cisco Incident Control 
System (Cisco ICS), 
Trend Micro Outbreak 
Prevention Service 
(OPS) 


Cisco Incident Control Server, page 8-13 


McAfee ePolicy 
Orchestrator 


McAfee ePolicy Orchestrator Devices, page 
8-8 


Network Associates 
VirusScan 


McAfee ePolicy Orchestrator Devices, page 
8-8 


Vulnerability Assessment 


eEye REM 


eEye REM 1.0, page 9-3 


Qualys QualysGuard 


Qualys QualysGuard Devices, page 9-5 


Foundstone Foundscan 


Foundstone FoundScan 3.0, page 9-1 


Host Operating Systems 


Windows Do one of the following: Syslog (pushed by SNARE agent) or event 
e Install and configure the SNARE agent Ga pease Me Ree 
e Create or edit an administrative account to mwas nee Aaa a 
ensure that it has permissions to pull the event ee Cee ne nor 
data Pull Method: Configure the Microsoft 
Windows Host, page 10-6 
Solaris _— Syslog (from Device) 
Sun Solaris and Linux Hosts, page 10-2 
Redhat Linux —_ Syslog (from Device) 
Sun Solaris and Linux Hosts, page 10-2 
Web Server 


Microsoft Internet 
Information Server 


Syslog (from SNARE agent) 


Install and Configure the Snare Agent for HS, 
page 12-1 


Sun iPlanet 


HTTP (from MARS Agent) 


Install and Configure the Web Agent on UNIX 
or Linux, page 12-7 
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Table 2-3 


Reporting and Mitigation Device Bootstrap Summary (continued) 


Reference Information 


Device Type/Name 


Bootstrap Summary 


Apache _— HTTP (from MARS Agent) 
Install and Configure the Web Agent on UNIX 
or Linux, page 12-7 

Web Proxy 


NetApp NetCache 


HTTP 


Network Appliance NetCache Generic, page 
13-1 


Database Server 


Oracle 


TCP 


SQLnet (from Host) 


Oracle Database Server Generic, page 11-1 


AAA Server 


Cisco Secure Access 
Control Sever (ACS) 


Syslog (from MARS Agent) 


Install and Configure the PN Log Agent, page 
14-7 (Cisco Secure ACS) 


Cisco Secure ACS 
Appliance 


Install and configure remote log agent. 


Syslog (from MARS Agent) on secondary 
host 


Supporting Cisco Secure ACS Solution 
Engine, page 14-2 


Install and Configure the PN Log Agent, page 
14-7 (Cisco Secure ACS) 


SNMP and Syslog Servers 


Generic Syslog Server 


Publish syslog messages to MARS Appliance. 


Enable SNMP access by MARS Appliance. 


Adding Generic Devices, page 10-1 


Generic SNMP Server 


Enable SNMP access by MARS Appliance. 


Adding Generic Devices, page 10-1 


Other 


Cisco Security Manager 


Enable HTTPS access by MARS Appliance 


Checklist for Security Manager-to-MARS 
Integration, page 16-6 


Bootstrapping Cisco Security Manager 
Server to Communicate with MARS, page 
16-12 


Add a Cisco Security Manager Server to 
MARS, page 16-13 


Adding Reporting and Mitigation Devices 


Three methods exist for adding reporting devices and mitigation devices to MARS: 


Manually add the devices one at a time. 


Add multiple devices using a seed file. 


Discover devices automatically using SNMP RO community strings. 
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From the Security and Monitor Devices page, you can add or edit the reporting devices and mitigation 
devices that MARS monitors. To access this page, click Admin > System Setup > Security and 
Monitor Devices. You can search for, add, edit, delete, change display status, and load devices from the 
seed file. 


The device support is categorized into three categories: 


e HW-Based Security Devices. Hardware-based devices represent routers, switches, and other 
dedicated security appliances. You can add such reporting devices by selecting the appropriate 
device. 


e SW-Based Security Devices. Software-based devices represent applications that reside on a host, 
rather than a dedicated appliance. You can add reporting device on a new host by selecting Add SW 
security apps on new host or on an existing host by selecting Add SW security apps on existing 
host. 


e On-Demand Security Services. Security services represent subscription-based services provided 
by vendors using a central security operations center (SOC) with remote monitoring nodes. These 
services, such as Qualys QualysGuard, represent systems from which MARS periodically pulls data. 
You can add such reporting devices by selecting the appropriate service. These devices also require 
you to define a schedule for pulling data (see Scheduling Topology Updates, page 2-39). 


The complete list of supported devices is presented in the Supported Devices and Software Versions for 
Cisco Security MARS Local Controller 4.2.x document. Devices are added to this list on an ongoing 
basis via software upgrade packages. See Install and Setup Guide for Cisco Security Monitoring, 
Analysis, and Response System for details on how to upgrade your MARS Appliance. 


MARS can also support any syslog or SNMP devices, even if they do not appear on the list of devices 
supported by the MARS. You can enter any syslog or SNMP device into the network topology, configure 
it to report data to the MARS, and query it using a free-form query. (See To Run a Free-form Query, page 
20-2.) 


For more information on adding devices, see: 
e Add Reporting and Mitigation Devices Individually, page 2-17 
e Add Multiple Reporting and Mitigation Devices Using a Seed File, page 2-20 
e Adding Reporting and Mitigation Devices Using Automatic Topology Discovery, page 2-25 


Regardless of the method that you have used to add the devices, you should also perform the following 
tasks: 


e Verify Connectivity with the Reporting and Mitigation Devices, page 2-26 
e Activate the Reporting and Mitigation Devices, page 2-27 


Add Reporting and Mitigation Devices Individually 


In general, you have two choices for adding devices that you want to monitor into your MARS. You can 
create a seed file or you can add each device manually. Seed file support is limited to a few device types, 
see Column E, page 2-23 for the devices supported. 


When manually configuring devices, select the devices that are most interesting to you. Once added, you 
can come back and edit them as necessary. Manual configuration is also useful when you add or change 
a single security device on your network. 
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Note 


Step 1 
Step 2 
Step 3 
Step 4 
Step 5 


Edit a Device 


Step 1 
Step 2 
Step 3 


Remember that you do not have to add all of the devices configuration information at once. You can start 
by adding the device’s name and its access IP address. You can always return later, when the MARS 
starts to report to you, and provide more details. 


To add a device manually, follow these steps 


Click Admin > System Setup > Security and Monitor Devices > Add. 
Select the device from the list. 

Enter the information needed to communicate with the device. 

Click Submit. 


Once add a device, you must click Activate for MARS to correctly process events received from that 
device. For more information, see Activate the Reporting and Mitigation Devices, page 2-27. 


Check the box next to the device. 
Edit the device’s settings. 
Click Submit. 


Upgrade the Device Type to a Newer Version 


You can change the Device Type version setting of a hardware-based security device. You cannot 
upgrade the version for software applications running on a host. To upgrade the software appliance 
version, you must remove the application from the host and add the newer one. 


This version change feature applies only to device types with the same vendor and model but different 
versions. Specifically, you can change the version for the following device types: 


e Cisco IDS 

e Cisco PIX 

e Cisco VPN Concentrator 
e NetScreen ScreenOS 


For example, you could change the settings for the device type Cisco PIX 6.1 to Cisco PIX 7.0 without 
having to delete the device and add it again. The benefit of matching the version setting to the deployed 
device is that it allows MARS to correlate any event types introduced in the more recent version. It also 
allows you to incrementally upgrade your reporting devices without having to worry about when to add 
that reporting device to MARS. The events that are correlated under one device type will be associated 
with the newer device type version when you make the change in MARS. 


To change the version of a device, follow these steps: 


User Guide for Cisco Security MARS Local Controller 
P28 78-17020-01 | 


Reporting and Mitigation Devices Overview 


| Chapter 2 


Step 1 
Step 2 


Step 3 
Step 4 


Step 5 
Step 6 


Adding Reporting and Mitigation Devices Ti 


Click Admin > System Setup > Security and Monitor Devices. 


Select the checkbox to the left of the device for which you want to change the version, and click Change 
Version. 


The Change the Device Type Version page appears, displaying the device name, vendor, model, and old 
version type information. 


Select the new version in the New Device Type Version list. 

To change the version of the device to the new version, click Submit. 

If any additional changes are available due to the version change, the Edit page appears. 
If the Edit page appears, make any desired changes and click Submit. 


Once you change the version setting for a device, you must click Activate for MARS to correctly process 
events received from that device. For more information, see Activate the Reporting and Mitigation 
Devices, page 2-27. 


Delete a Device 


When you define a reporting device in MARS, this device is added in two separate pages of the web 
interface. It appears where you have defined it, on the Admin > Security and Monitoring Devices page, 
as well as under the general device identification page under Management > IP Management. This 
duplication of content is based on the different functions that each of these pages serves. 


The Security and Monitoring Devices page configures the contact and device type information, whereas 
the IP Management page is used by the parser module to correlate known devices versus unknown 
devices. Typically when you delete a device from the Security and Monitoring Device page, you still 
want to retain the knowledge of that device in MARS so that historical incidents and events and cases 
can resolve to a known device; therefore, the device is not deleted from the IP Management page. 


Note 


Step 1 


Step 2 


Deleting a device does disassociate any historical incidents and events from the IP address. In other 
words, once you delete the device, you will not be able to find historical events for that device even if 
you re-add the device at a later date. 


However, if you need to delete and re-add a device to MARS, you must delete the device from both pages 
before you attempt to re-add the device. 


In addition, as devices are discovered on your network, they are added to the list of devices in the IP 
Management page. If you want to add a reporting device and find that you cannot, review the list of 
devices in the IP Management page to ensure that the device has not been auto-populated. If it has, you 
must first delete that device, then you can add it as a reporting device on the Security and Monitoring 
Devices page. 


To delete a device, follow these steps: 


Select one of the following pages: 
e Admin > Security and Monitoring Devices 
e Management > IP Management 


Check the box next to each device you want to delete. 
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Step 3 
Step 4 


Click Delete. 
On the confirmation page, click Submit. 


The device is deleted from the selected page. 


Delete All Displayed Reporting Devices 


Step 1 


Step 2 


Step 3 


You can perform this procedure from the Admin > Security and Monitoring Devices page. 


To delete all devices displayed on a page, follow these steps: 


On the Admin > Security and Monitoring Devices, select the checkbox to the left of the Device Name 
column heading at the top left of the table. 


All displayed devices are selected. 
Click Delete. 
A page appears prompting you to confirm that you want to delete the list of devices. 


Click Submit to delete all the selected devices. 


Add Multiple Reporting and Mitigation Devices Using a Seed File 


The seed file is a comma-delimited file with the file extension .csv (comma-separated value). Most 
spreadsheet programs let you import and export files as CSV files. 


The following is a sample seed file as exported from a popular spreadsheet program: 


10. dig dh, py PES SPRGNED ».)-)-CLSCO} p54 gS GG 95d 

192,168,229 .241,,,,108,TELNET,,,cCSRV$12*,EcSRVS128 p+ ¢e¢ eee 
10.1.1.83,,,,PIX,SSH,pix,Vpnspn12,,vPfwlne,,,,;;7777 
192,168, 151,169,),;PI4,SS8, pis), [pts12Z, ,potsl*al sy ecaenias 
10.4.2.4,,,,NETSCREEN, SSH,netscreen,nt*$scen25,,,;¢ +++ 44074 
10.4.2.3,,,,NETSCREEN, SSH,netscreen,nt*$scenl0,,,;; +++ +4471 
10, d4.1.261, 54,108; TELNET, , ,CUSCO, CASCOys pe ee ee eS 
10.4.2.1,,,,10S,TELNET,, ,QaS1*5ft,gtS*j15,,,,¢¢7pras 
10.4.2.2,,,,10S, TELNET, ,,QaS1*5ft,gtS*jl5,,e,¢rprre 
wanRouter,public,,,IOS,SNMP,,;,;;,¢+¢ +r rrree 
myPix63,,,,PIX,SSH,pix,test1,,test1234,,,,,7,7,,,,10.2.3.1 
MyPc,,,,WINDOWS,RPC,myname,mypaSS,,,;,;7 +777 477 
myPix70,,,,PIX7X,SSH,,;,;,¢;¢¢¢rreredy 
myids40.,.,.,, CUS@OLDS4x) SSLin 5 jeepers 

myi1ds50 474 CUSCOLPSSx; SSL yop jcrp ary ead 
myASA70,,,,ASA,SSH, ppp rrrrrrrcree 
myWindowsNT,,,,WindowsSNT,RPC,,;;¢¢ ++ 04 rrree 

MYEWSM2 3 95:59 FWSM SSH yp ppp Gen ad 


With the CSV file, you can enter the values, passwords, and information for each device that you want 
the MARS Appliance to monitor in its appropriate row and column. While the seed file is useful for 
getting the MARS Appliance started processing event data for most devices, you may need to use the 
Admin > System Setup > Security and Monitoring Devices page to fine-tune the device manually. In 
addition, you must Activate the devices that you add using a seed file (see Activate the Reporting and 
Mitigation Devices, page 2-27). 
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Devices that Require Custom Seed Files 


Some reporting devices represent the management consoles for the actual host- or node-based reporting 
devices. These consoles often represent centralized log servers for the devices they manage. However, 
for MARS to correctly correlate the logs for these centralized log servers, you must identify those host- 
or node-based reporting device. In some cases, MARS is able to dynamically learn of the hosts or nodes 
by parsing the logs. In other cases, you must use a seed file generated by management console to identify 
each of the managed reporting devices. 


Once you generate the seed file, you must import that seed file under the host that represents the 
management console in the MARS web interface to load the sensor module information from the CSV 
or seed file. The device types that use a custom seed file are as follows: 


Entercept. For more information, see Extracting Entercept Agent Information into a CSV file (for 
Entercept Version 2.5), page 7-1. 


IntruVert IntruShield. For more information, see Extracting Intruvert Sensor Information from the 
IntruShield Manager, page 6-22. 


Cisco Security Agent. While MARS can learn of the CSA agents dynamically, you can also import 
the initial list of agents using a custom seed file. For more information, see Export CSA Agent 
Information to File, page 7-6. 


Symantec AntiVirus. While MARS can learn of the Symantec AntiVirus agents dynamically, you 
can also import the initial list of agents using a custom seed file. For more information, see Export 
the AntiVirus Agent List, page 8-7. 


Devices that Require Updates After the Seed File Import 


When you add specific reporting devices using a seed file, you must edit them to complete the definition 
of the device before you can monitor them. Typically, these devices are IDS/IPS devices that monitor 
specific networks. The device types that you must update are as follows: 


Cisco IDS 4.x Devices. These sensors are defined by importing a MARS-specific seed file as 
defined in Load Devices From the Seed File, page 2-24. However, once you import a sensor, you 
must identify the monitored networks that it monitors. For more information, see Specify the 
Monitored Networks for Cisco IPS or IDS Device Imported from a Seed File, page 6-8. 


Cisco IPS 5.x Devices. These sensors are defined by importing a MARS-specific seed file as defined 
in Load Devices From the Seed File, page 2-24. However, once you import a sensor, you must 
identify the monitored networks that it monitors. For more information, see Specify the Monitored 
Networks for Cisco IPS or IDS Device Imported from a Seed File, page 6-8. 


IntruShield Senors. These sensors are defined by importing a custom seedfile; however, once you 
import the sensors, which appear as children of the IntruShield Manager host, you must identify the 
monitored networks for each sensor. For more information, see Add IntruShield Sensors Using a 
Seed File, page 6-27. 


Seed File Header Columns 


Table 2-4 describes the columns in the seed files and identifies valid values. If you do not enter a value 
for a given column, you must enter a comma to delineate that column. 
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Note Remember that you do not have to add all of the devices’ configuration information at once. You can 
start by adding the device’s name and its access IP address. You can always return later, when the MARS 
starts to report to you, and provide more details. 


Table 2-4 Seed File Column Description 
Column Type Entry 
Column A NAME OR IP The device’s name or IP address. (Mandatory) If the device name is provided 


and Column U is empty, MARS performs a DNS lookup to identify the 
address which will be used to populate the Access and Reporting IP fields 


Note If an IP address appears in Column U, that address overrides any 
address or derived address specified in Column A. However, the 
name value specified in Column A is used. 


Column B SNMP RO/RW The device’s SNMP RO community name here. 
Community 


Note MARS does not support the following characters in the SNMP RO 
community string: ' (single quote), " (double quote), < (less than 
symbol), and > (greater than symbol). 


Column C EMPTY Empty placeholder column. 
Column D EMPTY Empty placeholder column. 
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Table 2-4 Seed File Column Description (continued) 
Column Type Entry 
Column E DEVICE TYPE The device type designator. 


Note Some of the devices supported in the GUI cannot be entered via a 
CSV file. 
Use the following strings represent the desired device type: 
e asa: for Cisco ASA devices 
® cCiscoIDs4x: for applaince running Cisco IPS 4.x (not modules) 
® CiscoIps5x: for appliance running Cisco IPS 5.x (not modules) 
e Fwsm: for Cisco FWSM 1.1 
e prx: for Cisco PIX 6.0, 6.1, 6.2, and 6.3 devices 
e p1rx7x: for Cisco PIX 7.0 devices 
e tos: for Cisco IOS 12.2 (default) 


¢ switcH-catos: for Cisco Switch in Hybrid Mode 


e swrtcH-ios: for Cisco Switch in Native Mode 


e ExtTREeME: for Extreme ExtremeWare 6.x 


¢ NETSCREEN: for ScreenOS 4.0 and 5.0 
e winbows: for Window host 

e¢ Wwindows2000: for Windows 2000 host 
¢® Wwindows2003: for Windows 2003 host 
¢ wWwindowsnt: for Windows NT 4.x host. 
e souarts: for Solaris host 

e wrnux: for Linux host 


Note In the case of host files, Linux, Solaris, and Windows, MARS is 
configured by default to receive events from the hosts specified in a 
seed file. However, for a Windows host where the RPC settings are 
also specified in the seed file, MARS will both pull and receive logs 
from the host by default. 


Column F ACCESS TYPE The Access Type for this device. Your choices are: 
e TELNET 
e FTP 
e SSH 


e SNMP (default) 
e RPC (Windows only) 


In the RPC case, the username field (Column G) should be non-empty. The 
password can be provided in Column H. If RPC access type and username 
are given, the PULL flag is set by the backend in addition to the default 
RECEIVE flag. 
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Table 2-4 Seed File Column Description (continued) 
Column Type Entry 
Column G USER NAME The TELNET, SSH, FTP, or RPC user name. This column is only valid if you 
have used TELNET, SSH, or FTP in Column F. 
Column H SSH/FTP/RPC The SSH or FTP Password for the device. This column is only valid if you 
PASSWORD have used SSH or FTP in Column F. 
Column I TELNET The Telnet password for the device. 
PASSWORD 
Column J ENABLE The enable password (applicable only with FWSM, PIX, or IOS devices). 
PASSWORD 
Columns K EMPTY Emplty placeholder column. 
Column L EMPTY Emplty placeholder column. 
Column M EMPTY Emplty placeholder column. 
Column N EMPTY Emplty placeholder column. 
Column O EMPTY Emplty placeholder column. 
Column P EMPTY Emplty placeholder column. 
Column Q EMPTY Emplty placeholder column. 
Column R EMPTY Emplty placeholder column. 
Column S EMPTY Emplty placeholder column. 
Column T FTP LOCATION [if |The location for the FTP file. This location starts from the FTP root, not the 
Access Type =FTP] |sysroot. If, for example, the file is at <ftproot>/configdata/routerl.txt, 
using ./configdata/routerl.txt is correct. 
Column U Access/Reporting IP |The Access IP and Reporting IP address to use when populating this device. 
[optional] The MARS Appliance uses this address to communicate with the device. See 
Understanding Access IP, Reporting IP, and Interface Settings, page 2-8 


Load Devices From the Seed File 


Step 1 
Step 2 


Step 3 


Step 4 


Once you have completed the seed file, you must the CSV file on to the FTP server where you want to 
upload it. 


To load the file into the MARS, follow these steps: 


Click Admin > System Setup > Security and Monitor Devices > Load From Seed File. 


Enter the FTP Server’s IP address, the user name and password for the FTP server, the path, and the file 
name for the seed file. 


The FTP path starts from the FTP root, not from the sysroot for the configuration path. 
Click Submit. 


Once you have loaded devices from the seed file, return to each device. Continue to configure the devices 
and to add information such as reporting IP addresses, and SNMP information. 


Once add a device, you must click Activate for MARS to correctly process events received from that 
device. For more information, see Activate the Reporting and Mitigation Devices, page 2-27. 
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Note 


Using a seed file to define the reporting devices replaces the manual definition of the device; however, 
the topology information will not be available. After adding the reporting devices via a seed file, you 
must either manually discover each device by selecting the device, clicking Edit, and then clicking the 
Discover button or by scheduling a topology discovery. In addition, some device types required that you 
define additional settings (see Devices that Require Updates After the Seed File Import, page 2-21). 


Adding Reporting and Mitigation Devices Using Automatic Topology Discovery 


On the Admin page, under the Topology Discovery Information section, three links exist, allowing you 
to define the settings required to discover reporting and mitigation devices automatically. These links 
are: 


e Community String and Networks. Allows you to define SNMP RO community strings on a per 
network or IP range basis. Networks and SNMP RO stings can overlap. At least one SNMP string 
must be defined before discovery is attempted. 


e Walid Networks. Identifies the set of networks and IP ranges that you want to discover. You should 
also define one or more SNMP targets. If no SNMP targets are defined, MARS uses it’s own gateway 
as the SNMP target. SNMP targets should be layer 3 gateway devices, such as a router or firewall 
with SNMP RO community strings defined and discovery permitted; they should also be defined on 
a per network or per range basis if you wish to separate the discovery using schedule rules. At least 
one valid network must be defined before discovery is attempted. 


e¢ Topology/Monitored Device Update Scheduler. While not required for discovery, it does allow 
you to increase the frequency of topology discovery and further refine the potential depth of a 
discovery based on a particular schedule rule. The default schedule rule is once a month for all valid 
networks. However, if no valid networks are defined, the process wakes up, sees no valid networks 
are defined, and quits. Each schedule rule allows you to select which networks, as defined within 
the list of valid networks and ranges, that should be discovered according to frequency also specified 
in the rule. As connected networks often exist, you can refine which networks are discovered by 
ensuring that separate schedule rule exists for each network that you do not want to be automatically 
discovered as part of a connected network. 


Based on the networks defined within the schedule rules, MARS starts with the first SNMP target 
associated with those networks or ranges as defined under Valid Networks and attempts to discover that 
device using SNMP discovery. The discovery process continues as long as the target device provides 
additional routes and the addresses of such routes are part of the networks in another schedule rule. The 
process also iterates through each SNMP target that is defined. The entire discovery process is limited 
based on the schedule rule’s bounding networks, the SNMP targets, the valid network and IP ranges, and 
the SNMP RO community strings, which are defined on a per network basis. Networks and SNMP RO 
community stings can overlap, in which case MARS tries each string against the gateway addresses 
discovered within that network. The discovery process only discovers Layer 3 gateway devices, such as 
routers and firewalls. It does not discover hosts, unless those hosts are defined as the explicit target 
within a schedule rule (see Scheduling Topology Updates, page 2-39). 


As the discovery process identifies supported reporting and mitigation devices, it adds those devices to 
the Monitoring and Security Devices list (Admin > Monitoring and Reporting Devices), identifying 
them by the Reporting IP. You can later edit these discovered devices to provide Access IP information 
and perform more thorough device-level discovery. Once a device is listed under Monitoring and 
Reporting Devices, it may be rediscovered, but it will not be added again unless it has been properly 
deleted (see Delete a Device, page 2-19). 
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For more information on these settings, see: 
e Configuring Layer 3 Topology Discovery, page 2-36 
e Scheduling Topology Updates, page 2-39 


Note 


Once the discovery process is complete, you must click Activate for MARS to correctly process events 
received from that device. For more information, see Activate the Reporting and Mitigation Devices, 
page 2-27. 


Verify Connectivity with the Reporting and Mitigation Devices 


S 


After loading the seed file or manually adding devices, you can verify that the devices were loaded by 
clicking Admin > System Setup > Security and Monitor Devices. You should see the devices that you 
have added populating this page. 


You can test the devices by checking the box next to the name of the device and clicking Edit. On the 
device’s page, click Discover or Test Connectivity. The UI displays a “holding pattern” screen while it 
connects to the device. When complete, it shows you the device’s discovery screen. 


Note 


Some devices cannot be checked for connectivity nor can be discovered. The next section, Discover and 
Testing Connectivity Options, page 2-26, contains a list of devices that can be checked or discovered. 


Discover and Testing Connectivity Options 


When you add a device, you should check its connectivity or perform the discovery. Checking a device’s 
connectivity or discovery analyzes the device’s configuration, checks that MARS can process its events, 
and that MARS can understand its NAT information. 


You can test these devices for connectivity or perform discovery: 


e Cisco IOS 
e Cisco PIX 
e Cisco ASA 


e Cisco Switch CatOS 

e Cisco Switch IOS 

e Cisco IDS 

e Cisco IDSM 

e Cisco FWSM 

e Cisco Security Manager server 
e Cisco VPN Concentrator 4.x 

e Check Point 

e Extreme ExtremeWare 6.x 


e NetScreen 
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Run a Reporting Device Query 


\ 


Another method to see the added devices, is to run a query with the display format: Reporting Device 
Ranking. 


Note 


Step 1 
Step 2 
Step 3 
Step 4 
Step 5 


You might not see all of the devices that you loaded using the seed file right away because of lag, network 
size and traffic. If you do not see a device after waiting, it could be due to input error. 


To run a reporting device ranking query, follow these steps: 


Click the Queries / Reports tab. 

On the Queries page, in the Query Event Data table, click Event Type in the Display Format column. 
Select Reporting Device Ranking. 

Click Apply. 

Click Submit to run the query. 


Activate the Reporting and Mitigation Devices 


After you have added reporting devices and mitigation devices to MARS, you must activate those 
devices before MARS begins to fully process the data provided by those devices. This processing is 
different from those devices discovered on the network, where the logs sent to the appliance are stored, 
but your ability to interact with that data is limited to queries and reports. Typically, MARS runs 
inspection rules and generates notifications only against the data retrieved from activated devices. 


Once a device is known to the MARS Appliance, all data provided by that particular device can be 
normalized and sessionized, which enables that device’s data to be used to fire an incident 


Note 


Default installations of MARS do not fire incidents based on data received from unknown devices. 
However, you can still enable this by creating one or more rules that use keyword search. A device must 
be defined for the MARS to be able to parse and sessionize the event data. The act of parsing the event 
data correctly is what ensures rules fire more accurately. 


Tip 


Step 1 


Step 2 


You must click Activate whenever you add or modify rules, drop rules, reports, or add or modify any 
options or settings under in the Admin tab other than those on the User Management subtab. Otherwise, 
the changes that you make will not take effect. 


To activate added devices, follow these steps: 


For each device that you want to add, provide the device details and click Submit to add the device. 


The Submit action stores the device details in the database. Once you click Submit, your work is saved, 
even if you drop the administrative connection before clicking Activate. 


Once you have all of the devices desired for this administrative session, click Activate. 
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The Activate action differs from Submit in that MARS begins to inspect and generate notifications about 
the data provided by the devices. 


je 


Tip If you are adding or editing several devices, it is better for the system to click Activate for 
several changes rather than for each individual change. 


Data Enabling Features 


Adding a the reporting devices and mitigation devices is the primary method of providing MARS with 
the data required to study the activities on your network. However, other features, both within the web 
interface and as part of configuring the devices, can provide MARS with additional data, which is used 
to refine the views it provides and to assist in the improving the overall effectiveness of the system. We 
think of these features as data enabling features. 


This section contains the following topics: 
e Layer 2 Discovery and Mitigation, page 2-29 


Enable SNMP community strings to support the discovery the network topology. Allows for 
mapping to the port level for switches. Combined with 802.1x support required by NAC, this setting 
can resolve MAC address level settings for attached and wireless nodes on the network. 


e Networks for Dynamic Vulnerability Scanning, page 2-29 


Enables a Nessus-based scan of the targeted hosts. Nessus also uses nmap for OS fingerprinting and 
port scanning during a vulnerability assessment scan. These scans are conducted in response to 
suspicious activity to determine whether the attempted attack is successful or likely to succeed based 
on information such as target operating system type, patch level, and open ports on the host. 


e Understanding NetFlow Anomaly Detection, page 2-30 


By enabling NetFlow, MARS can detect anomalies in traffic and network usage by comparing new 
events with summary data. When anomalies are detected, MARS begins to store full NetFlow data. 
By default, full NetFlow data is not stored by MARS unless an incident is identified. 


¢ Host and Device Identification and Detail Strategies, page 2-36 


Details about reporting devices and the hosts that are on your network aids in the elimination of false 
positives, as well as improves the performance of MARS in assessing events. 


¢ Configuring Layer 3 Topology Discovery, page 2-36 


Layer 3 topology discovery aids in attack path analysis, as well as the population of the topology 
graph in the web interface. 


e Scheduling Topology Updates, page 2-39 


Topology update schedules are a critical part of many of the data enabling features, including 
discovery of Layer 2 and Layer 3 devices, as well as pulling information from specific reporting 
devices. 


e¢ Configuring Resource Usage Data, page 2-41 


MARS can collect additional data from a select set of reporting devices, which is used to provide 
reports about CPU utilization, memory utilization, and device saturation. This data can be helpful 
in detecting anomalies as well in network capacity planning. 
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e Configuring Network Admission Control Features, page 2-42 
Describes how to accomplish full NAC awareness, what it provides, and what products are required. 


e Configuring Distributed Threat Mitigation 
http://www.cisco.com/en/US/products/ps624 |/products_configuration_example09 1 86a008067a2b 
0.shtml 


Describes how to accomplish full DTM awareness, the features it provides, and what products are 
required. 


e MARS MIB Format, page 2-43 


Describes the format of the MARS MIB, which helps integrate with other SNMP-based management 
applications on your network. 


Layer 2 Discovery and Mitigation 


Make sure that all the L2 devices have the SNMP RO community strings specified in the web interface 
for L2 mitigation, even if the access type is not SNMP. (See False Positive Confirmation, page 19-6 for 
more information on mitigating an attack.) 


The SNMP RO community string is always required on Layer 2 devices for L2 mitigation. L2 devices 
must be added manually—there is no automatic discovery for these device. 


Note 


MARS does not support the following characters in the SNMP RO community string: ' (single quote), " 
(double quote), < (less than symbol), and > (greater than symbol). 


MARS does not discover L2 devices automatically as it does with L3 devices. 


Note 


L2 devices must be added manually; there is no automatic discovery for these devices. Make sure all the 
L2 devices (switches) have the SNMP RO community strings specified in the web interface, even if the 
access type is not SNMP. The SNMP RO community string is always required on L2 devices for L2 
mitigation. 


You can specify which L3 devices to discover by specifying networks and SNMP RO community values, 
as defined in Configuring Layer 3 Topology Discovery, page 2-36. 


The reason is MARS does not scan the network for devices. Therefore, you must manually add L2 
devices using the web interface or a CSV file. Assuming that device discovery permission has been 
provided, L3 devices are discovered automatically using the route information provided by monitored 
gateways. Once devices are loaded/added in the web interface, user can use the topology scheduler 
feature to update the configuration of both L2 and L3. 


For L2 devices SNMP access type is sufficient with RO community. But for mitigation, MARS requires 
SNMP RW community access. If SNMP RW community is not possible, select TELNET/SSH access 
type with SNMP RO Community. 


Networks for Dynamic Vulnerability Scanning 


With dynamic vulnerability scanning, the MARS probes the networks that you have specified for 
weaknesses. These automatic scans commence after a rule has fired that indicates an attack is in 
progress. Once an attack is underway, these scans accomplish the following: 
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e return information that determines if the attack failed 
e return information that determines if the attack likely succeeded 
e return false positive information 


e assign severity to firing events and incidents 


Select a Network for Scanning 


To select a network for scanning, follow these steps: 


Step 1 Click the Select radio button. 
Step2 Click a network to scan. 
Step3 = Click Add. 

Step4 Repeat Step | through Step 3. 
Step5 = Click Submit when ready. 


Create a Network IP Address for Scanning 


To create a network address that you can use to define the scan settings, follow these steps: 


Step 1 Click the Network IP radio button. 
Step2 Enter the Network IP address and Mask. 
Step3 = Click Add. 


Create a Network IP Range for Scanning 


To create a range of network addresses that you can use to define the scan settings, follow these steps: 


Step 1 Click the IP Range radio button. 
Step2 Enter the range of IP addresses. 
Step3 = Click Add. 


Understanding NetFlow Anomaly Detection 


NetFlow is a Cisco technology that supports monitoring network traffic and is supported on all basic IOS 
images. NetFlow uses an UDP-based protocol to periodically report on flows seen by the Cisco IOS 
device. A flow is a Layer 7 concept that consists of a session set up, data transfer, and session teardown. 
For every flow, a NetFlow-enabled device record several flow parameters including 


e Flow identifiers, specifically source and destination addresses, ports, and protocol 
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e Ingress and egress interfaces 
e Packets exchanged 
e Number of bytes transferred 


Periodically, a collection of flows and its associated parameters are packaged in an UDP packet 
according to the NetFlow protocol and sent to any identified collection points. Because data about 
multiple flows is recorded in a single UDP packet, NetFlow is an efficient method of monitoring high 
volumes of traffic compared to traditional methods, including SYSLOG and SNMP. 


The data provided by NetFlow packets is similar to that provided by SYSLOG, SNMP, or Checkpoint 
LEA as reported by enterprise-level firewalls, such as Cisco PIX, NetScreen ScreenOS, and Checkpoint 
Firewall-1. The difference being that NetFlow much more efficient. To receive comparable syslog data 
from a firewall device, the syslog logging level on the firewall must be set to DEBUG, which degrades 
firewall throughput at moderate to high traffic loads. 


If NetFlow-enabled reporting devices are positioned correctly within your network, you can use NetFlow 
to improve the performance of the MARS Appliance and your network devices, without sacrificing 
MARS’s ability to detect attacks and anomalies. In fact, NetFlow data and firewall traffic logs are treated 
uniformly as they both represent traffic in the network. 


This section contains the following topics: 
e How MARS Uses NetFlow Data, page 2-31 
e Guidelines for Configuring NetFlow on Your Network, page 2-32 
e Enable Cisco IOS Routers and Switches to Send NetFlow to MARS, page 2-32 
e Configuring Cisco CatIOS Switch, page 2-34 
e Enable NetFlow Processing in MARS, page 2-34 


How MARS Uses NetFlow Data 


wy 


Note 


When MARS is configured to work with NetFlow, you can take advantage of NetFlow’s anomaly 
detection using statistical profiling, which can pinpoint day zero attacks like worm outbreaks. MARS 
uses NetFlow data to accomplish the following: 


e Profile the network usage to determine a usage baseline 
e Detect statistically significant anomalous behavior in comparison to the baseline 
e¢ Correlate anomalous behavior to attacks and other events reported by network IDS/IPS systems 


After being inserted into a network, MARS studies the network usage for a full week, including the 
weekend, to determine the usage baseline. Once the baseline is determined, MARS switches to detection 
mode where it looks for statistically significant behavior, such as the current value exceeds the mean by 
2 to 3 times the standard deviation. 


By default, MARS does not store the NetFlow records in its database because of the high data volume. 
However, when anomalous behavior is detected, MARS does store the full NetFlow records for the 
anomalous entity (host or port). These records ensure that the full context of the security incident, such 
as the infected source and destination port, is available to the administrator. This approach to data 
collection provides the intelligence required by an administrator without affecting the performance of 
the MARS Appliance. Storing all NetFlow records consumes unnecessary CPU and disk resources. 


MARS only supports NetFlow version 5 and version 7. 
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Guidelines for Configuring NetFlow on Your Network 


Ideally NetFlow should be collected from the core and distribution switches in your network. These 
switches, together with the NetFlow from Internet-facing routers or SYSLOG from firewalls, typically 
represent the entire network. With this in mind, review the following guidelines before deploying 
NetFlow in your network: 


MARS normalizes NetFlow and SYSLOG events to prevent duplicate event reporting from the same 
reporting device. 


Review VLANS in switches and pick several VLANs for which the traffic volume is low. This 
approach allows you to slowly integrate NetFlow and become comfortable with using it in your 
environment. 


Be aware of existing CPU utilization on NetFlow capable devices. For more information on 
understanding how NetFlow affects the performance of routers and network throughput, see the 
following link: 


http://www.cisco.com/en/US/tech/tk8 12/technologies_white_paper0900aecd802a0eb9. shtml 
Consider using a sampling of NetFlow data 10:1 100:1 ratio’s in highly utilized VLANS. 


Be selective in using NetFlow, you to not need to enable it on all NetFlow-capable devices. In fact, 
such usage can create duplicate reporting of events, further burdening the MARS Appliance. 


MARS uses NetFlow versions 5 and 7. Ensure that the version of Cisco IOS software or Cisco 
CatOS running on your reporting devices supports at least one of these NetFlow versions. 


The taskflow for configuring NetFlow to work with MARS is as follows: 


1. 
2. 


Identify the reporting devices on which to enable NetFlow. 


Enable NetFlow on each identified reporting device and direct the NetFlow data to the MARS 
Appliance responsible for that network segment. 


Verify that all reporting devices are defined in the MARS web interface. 
Enable NetFlow processing in the MARS web interface. 


Allow MARS to study traffic for a week to develop a usage baseline before it beings to generate 
incidents based on detected anomalies. 


The following tasks provide guidance on the required device configuration: 


Enable Cisco IOS Routers and Switches to Send NetFlow to MARS, page 2-32 
Enable NetFlow Processing in MARS, page 2-34 


Enable Cisco IOS Routers and Switches to Send NetFlow to MARS 


For more information on NetFlow and configuring the settings in Cisco IOS, refer to: 


http://www.cisco.com/univercd/cc/td/doc/product/software/ios 124/124cg/hnf_c/nfb_ov.htm 


Before you configure NetFlow from MARS, you must first configure it on the router or switch. 


To enable NetFlow on a Cisco IOS router or switch and to push those events to the MARS Appliance, 
follow these steps: 


Step 1 Log in to the Cisco IOS router or switch with administrator’s privileges. 


Step2 Enter the following commands: 
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Purpose 


enable 


Turn on enable mode. 


configure terminal 


Enter global configuration mode. 


Note Commands in this mode are written to the running 
configuration file as soon as you enter them (using the Enter 
key/Carriage Return). 


ip flow-export destination 
<MARS_IP_address> 
<UDP_port> 


Enables the data export to the MARS Appliance on UDP port 2055 
(assuming the default port is used). MARS_IP_address is the IP 
address of the MARS Appliance that is responsible for processing 
the NetFlow events for this reporting device. UDP_port is the 
default UDP port to send NetFlow (the default port is 2055). 


ip flow-export source 
<syslog_interface_name> 


e Set the source IP for the interface to send the NetFlow. The 
syslog_interface_name value should be the interface attached 
to the network through which the MARS Appliance is 
reachable, and it must equal the syslog source interface name. 


ip flow-export version 


<version_number> 


Identifies which version of NetFlow, 5 or 7, to use when generating 
events. Cisco recommends using version 5 if supported. 
version_number is either 5 or 7. MARS only supports NetFlow 
versions 5 and 7. 


ip flow-cache timeout active 
5 


Configures the flow timeout. This timeout value breaks up 
long-lived flows into 5-minute segments. You can choose any 
number of minutes between | and 60; however, selecting the default 
of 30 minutes will result in spikes appearing in utilization reports. 


ip flow-cache timeout 
inactive 15 


Ensures that those flows that have finished are exported in a timely 
manner. 


For each interface in the device, enter the following commands: 


Command 


Purpose 


interface <interface_name> 


Specifies the interface for which you want to enable NetFlow and it 
enters the interface configuration mode. interface_name is the name 
of the interface to which the MARS is connected. This command 
varies based on the device type. For example, 


interface type slot/port-adapter/port (Cisco 7500 series 
routers) 


interface type slot/port (Cisco 7200 series routers) 


ip route-cache flow 


Enables NetFlow for the selected interface. 


To verify that NetFlow is enabled correctly, enter the following commands: 


show ip flow export 


show ip cache flow 


To exit enable mode, enter the following command: 
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exit 


Configuring Cisco CatlOS Switch 


Some Cisco Catalyst switches support a different implementation of NetFlow that is performed on the 
supervisor. With the cache-based forwarding model, which is implemented in the Catalyst 55xx running 
the Route Switch Module (RSM) and NetFlow Feature Card (NFFC), the RSM processes the first flow 
and the remaining packets in the flow are forwarded by the Supervisor. This support is also implemented 
in the early versions of the 65xx with MSFC. The deterministic forwarding model used in the 65xx with 
MSFC2 do not use NetFlow to determine the forwarding path, the flow cache is only used for statistics 
as in the current IOS implementations. In all of these configurations, flow exports arrive from both the 
RSM/MSFC and the Supervisor engines as distinct streams. 


The router-side running IOS is configured as specified in Enable Cisco IOS Routers and Switches to 
Send NetFlow to MARS, page 2-32. However, to configure the he CatlOS NetFlow Data Export, use the 
following commands: 


set mls flow full 

set mls nde version 5 

set mls nde <MARS_IP_address> 2055 
set mls nde enable 


From a user’s perspective, the switch is only running IOS when the 65xx is running in Native mode. 


Enable NetFlow Processing in MARS 


Step 1 


Once you have enabled NetFlow on your routers or switches and you have directed those devices to 
publish NetFlow data to the MARS Appliance, you must configure the appliance to process that data. 
This configuration involves determining how to store data, as well as identifying which networks you 
want to process for anomalous behavior. Both of these options can affect the rate at which MARS can 
process events: storing the full event data rather than summary data burdens the system with writing 
large volumes of data rather than processing new incoming events. Also, by not specifying a select set 
of networks, MARS studies all networks. 


Click Admin > System Setup > NetFlow Config Info. 
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NetFlow Configuration 


Global NetFlow UDP Port: 
Enable NetFlow Processing: Yes @ No ¢ 
Always Store NetFlow Records: Yes ¢ Nog 


NetFlow Yalid Network Addresses 


*] Add 
C Network 7 | | | 
ne II 


ewrense: (HW WIL IL IC I_1 


© Back Info Submit 


143229 


Step2 Under NetFlow Configuration, enter the NetFlow Global NetFlow UDP Port. This is the default port 
for MARS to listen for NetFlow; the default value is 2055. 


Note This value must match the value you entered in the “ip flow-export destination” command when 
configuring the router (see Enable Cisco IOS Routers and Switches to Send NetFlow to MARS, page 
2-32. Also, verify you have enabled this traffic to flow between the router or switch and the MARS 
Appliance on any intermediate gateways, such as routers and firewalls. 


Step3 Choose whether to Enable NetFlow Processing. 

e Yes tells MARS to process the NetFlow logs. 

e No disables the processing of NetFlow data into the MARS. 
Step4 Choose whether to Always Store NetFlow Records. 


e Yes tells MARS to store all of the NetFlow events in the database. Selecting this option can slow 
down the system by greatly decreasing the number of events per second that MARS is able to 
process. 


e No tells MARS to store only anomalies. The MARS detects anomalies by using two dynamically 
generated watermarks comparing the previous data against current data. When the data breaches the 
first watermark, MARS starts to save that data. When the data rises above the second watermark, 
MARS creates an incident. 


Step5 Under NetFlow Valid Network Addresses, you can enter one or more for networks you want to monitor 
and use the << Add button to add them. 


e Specifying one or more networks causes MARS to generate NetFlow-based anomalies that occur 
only on the specified networks. 
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Step 6 
Step7 


\ 


Note To reduce the memory usage and increase performance of the appliance, you can configure 
MARS to profile hosts belonging to a set of valid networks. 


e Leaving this value blank (not specifying any networks) causes MARS to examine all networks for 
anomalous behavior based on the NetFlow events. 


Click Submit to save your changes. 
To enable NetFlow processing by the MARS Appliance, click Activate. 


Before MARScan start detecting anomalies based on NetFlow data, it must first develop a baseline for 
network behavior. It takes a full week, including the weekend, for MARS to develop such a baseline. 
After this period has elapsed, MARS can start generating incidents based on NetFlow’s anomaly 
detection. 


Host and Device Identification and Detail Strategies 


MARS studies many events at the network layer, relying on firewalls, routers, and IPS devices to identify 
anomalies and suspected incidents at a layer above the endpoint hosts that are the source or destination 
of network sessions. If operating exclusively at this network layer, MARS can generate a number of false 
positive incidents that must be manually investigated. However, several features exist that allow you to 
provide host-level details to MARS: 


e Enable event reporting from the hosts on your network. MARS can receive, and in some cases, pull 
event data directly from the hosts on your network. This additional data allows MARS to verify the 
success of some attacks, as well as to report issues with the operation of the host, such as including 
them in “device down” reports if they are inaccessible. For more information on configuring the 
hosts and MARS to pull or receive data from those hosts, see the following topics: 


- Adding Generic Devices, page 10-1 
- Sun Solaris and Linux Hosts, page 10-2 
- Microsoft Windows Hosts, page 10-4 


e Manually identify the operating system type and network services running on discovered hosts. For 
more information, see Define Vulnerability Assessment Information, page 10-11 and Identify 
Network Services Running on the Host, page 10-13 


e Manually identify common hosts and nodes in your network by adding other devices via 
Management > IP Management. This additional data allows you to identify those hosts that are 
likely to be involved in network sessions without having to configure the hosts to provide event data 
directly to MARS. This open allows you to provide vulnerability assessment information to assist 
in the reduction of false positives. For more information on adding hosts manually, see Add a Host, 
page 23-4. 


Configuring Layer 3 Topology Discovery 


For the MARS to reach full operability, you must specify its community strings and select the networks 
that you want to discover. Once the appliance discovers these networks, you get a more accurate view of 
MAC addresses, end-point lookup (attack paths), and network topology. Topology discovery enables 
operation level three, see Levels of Operation, page 2-1 for more information. 
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See Figure 17-13 on page 17-7 for a view of the topologies. 


wy 


Note Remember to activate additions and changes to your community strings and valid networks by clicking 
Activate. 


Add a Community String for a Network 


To add a community string for a network IP, follow these steps: 


Step1 To open the Community Strings and Networks page, click Admin > Community Strings and 
Networks. 


Community Strings and Networks 


Community String: 
© Network 1%) [——-- 
Mask: ; } L 


Cc IP Range: ! { | ]-| lI { 


Step2 Click the Network IP radio button. 

Step3 = Enter the Community String, Network IP address, and Mask. 

Step4 Click Add. 

Step5 Repeat Step 2 through Step 4 for all the community strings that you want to add. 


Step6 Click Submit to commit these additions. 


Add a Community String for an IP Range 


To add a community string for an IP range, follow these steps: 


Step1 To open the Community Strings and Networks page, click Admin > Community Strings and 
Networks. 


Step2 Click the IP Range radio button. 

Step3 = Enter the Community String and its IP Range. 

Step4 Click Add. 

Step5 Repeat Step 2 through Step 4 for all the community strings that you want to add. 


Step6 Click Submit to commit these additions. 
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You can add multiple community strings for the same network by adding similar entries. 


Add Valid Networks to Discovery List 


wy 


Adding valid networks confines the MARS to discover the networks that you want. MARS uses this 
information to create topologies, find MAC addresses, and for end-point lookup (attack paths). 


Note 


Step 1 
Step 2 


Step 3 
Step 4 
Step 5 


You can only specify networks for the zone where the MARS Appliance operates. 


To add valid networks, follow these steps: 


Click Admin > Valid Networks to open the Valid Networks page. 
Enter the SNMP Target’s IP address. 


The SNMP target is the entry-point where the MARS starts discovering devices on a network. It typically 
identifies an address on a default gateway of the network. 


Click either Network IP or Network Range to define the scope of the scan. 
Enter the appropriate information. 


Click Submit. 


Remove Networks from Discovery List 


Step 1 
Step 2 
Step 3 


To remove a network, follow these steps: 


Click Admin > Valid Networks to open the Valid Networks page. 
Click the network that you want to remove. 


Click Remove. 


Discover Layer 3 Data On Demand 


Step 1 
Step 2 
Step 3 


You can schedule topology discovery, as defined in Scheduling Topology Updates, page 2-39. However, 
you can also initiate an on-demand discovery. 


To perform an on-demand discovery, follow these steps: 


Click Admin > Valid Networks to open the Valid Networks page. 
Verify that the list of Valid Network Addresses contains the networks that you want to discover. 


Click Discover Now. 
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You can configure MARS to run automatic topology updates on devices, networks, and groups of 


networks. Scheduling topology updates is a critical part of keeping the MARS Appliance abreast of 


changes in the network and of changes to the configuration settings of the reporting devices and 
mitigation devices. This operation is similar to clicking Discover when defining a reporting device. 


Configuration discovery depends on the device type, proper authorization, an access type, such as Telnet 
or SSH, and an access IP address. When device discovery is performed, MARS contacts the device and 
conducts a topology and configuration discovery. This discovery collects all of the route, NAT, and 
ACL-related information for the device or admin context. In addition, the name of the device may change 
to hostname.domain format if it was not already entered as such. If discovering a device that supports 

them, MARS also discovers information about modules, admin contexts, and security contexts. Another 


effect of scheduled updates is that MARS keeps the network diagram and attack paths current in the 


Dashboard. 


This feature also allows you to pull data from those devices that require interval-based polling. The list 
to devices that require such polling are: 


Qualys QualysGuard 


eEye REM 


FoundStone FoundScan 


Check Point log servers 


Figure 2-1 


Name: 


Example Scheduled Update for eEye REM 
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c 
c 


Cc 


«] Add C Select: 
Networ' ° 
Remove [> Nath ate ye 
Mask: 
c IP Range: 
Schedule Time of Day Days 


Run On Demand Only 
Daily 


eekly 


Monthly 


foist po2nd po 3rd po4th po Sth po éth 


path po sth po ioth po iith po izth poisth po 14th 
po isth poisth po i7th po isth Po igsth fo 2oth fo 2ist 


Schedule a Network Discovery 


To add a network for scheduled discovery, follow these steps: 


Step1 Click Admin > Topology/Monitored Device Update Scheduler. 


The Topology/Monitored Device Update Scheduler page displays. 
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Step2 Click Add. 
Step3 Enter a name for the network (or group of networks). 
Step4 Select or enter your networks: 
e Click the Select radio button, and select a network from the list. 
e Click the Network IP radio button, and enter the IP address and Mask. 
e Click the IP Range radio button, and enter the IP ranges. 
Step5 Click Add to move the network into the selected field. 
e To remove an item in the selected field, click it to highlight it, and click Remove. 
Step6 In the schedule table, select the appropriate radio button and its time criteria: 
e Run On Demand Only 
e Daily and the Time of Day 
e Weekly, the Time of Day, and the Days 
¢ Monthly, the Time of the Day, and the Dates 
Step7 Click Submit. 


To edit a scheduled topology discovery 


Step 1 Check the box next to the Topology Group. 
Step2 Click Edit. 
Step3 Click Add to move the network into the selected field. 
e To remove an item in the selected field, click it to highlight it, and click Remove. 
Step4 In the schedule table, select the appropriate radio button and its time criteria: 
e¢ Run On Demand Only 
e Daily and the Time of Day 
e Weekly, the Time of Day, and the Days 
e Monthly, the Time of the Day, and the Dates 
Step5 Click Submit. 


To delete a scheduled topology discovery 


Step 1 Check the box next to the Topology Group. 
Step2 Click Delete. 
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To run a topology discovery on demand 


wy 


Note 


Step 1 
Step 2 


You can run any scheduled or on-demand topology discoveries at any time. 


Check the box next to the Topology Group. 
Click Run Now. 


Configuring Resource Usage Data 


While the Monitor Resource Usage box appears on every host and reporting device, only three device 
types actually provide resource usage data to MARS: 


e Cisco IOS routers and switches 
e Cisco PIX 
e Check Point devices 


For these three devices, MARS can provide data about CPU utilization, memory utilization, and device 
saturation. 


To enable the collection of resource usage data, you must ensure that the resource usage-specific events 
are logged by the reporting devices, that the SNMP RO community string is set, that those devices 
forward the events to MARS, and that the device is defined in the web interface as a reporting device or 
mitigation device. In addition, you must select Yes in the Monitor Resource Usage box of the General 
tab for each supported reporting device. 


Once configured, MARS uses SNMP to poll the device every 5 minutes for the following SNMP OIDs: 
e Bytes in/out of every interface on the device (Cisco IOS, Cisco PIX) 
e Number of current connections (Cisco PIX, Check Point) 
e CPU of last second and last 60 seconds (Cisco IOS, Cisco PIX) 
e Memory free/used (Cisco IOS, Cisco PIX) 


It also detects anomalous resource utilization if the consumption is significantly higher than the hourly 
average. 


The following resource usage data reports are available: 
e Resource Utilization: Bandwidth: Inbound - Top Interfaces 
e Resource Utilization: Bandwidth: Outbound - Top Interfaces 
e Resource Utilization: CPU - Top Devices 
e Resource Utilization: Concurrent Connections - Top Devices 
e Resource Utilization: Errors: Inbound - Top Interfaces 


e Resource Utilization: Errors: Outbound - Top Interfaces 


e Resource Utilization: Memory - Top Devices 
You can define custom rules, reports, and queries about resource usage based on the following events: 


e CPU Utilization Higher Than 50% 


| 78-17020-01 


User Guide for Cisco Security MARS Local Controller | 


Chapter2 Reporting and Mitigation Devices Overview | 


HZ Data Enabling Features 


e CPU Utilization Higher Than 75% 
e CPU Utilization Higher Than 90% 
e CPU Utilization Abnormally High 
¢ Memory Utilization Higher Than 50% 
¢ Memory Utilization Higher Than 75% 
e Memory Utilization Higher Than 90% 
e Memory Utilization Abnormally High 
There is also is pre-defined resource utilization inspection rule: 
e System Rule: DoS: Network Device - Success Likely 
e System Rule: DoS: Network - Success Likely 


e System Rule: Resource Issue: Network Device 


Configuring Network Admission Control Features 


Network Admission Control (NAC) is a Cisco Systems sponsored industry initiative that uses the 
network infrastructure to enforce security policy compliance on all devices seeking to access network 
computing resources, thereby limiting damage from viruses and worms. 


Using NAC, organizations can provide network access to endpoint devices such as PCs, PDAs, and 
servers that are verified to be fully compliant with established security policy. NAC can also identify 
noncompliant devices and deny them access, place them in a quarantined area, or give them restricted 
access to computing resources. 


MARS supports the NAC initiative by storing and reporting about the NAC-based events generated by 
the various reporting devices on your network. The devices include:. 


e Cisco Trust Agent. While CTA does not report to MARS, it does report discovered settings to the 
Cisco network devices, from which MARS collects events. 


e 3rd-party 802.1x Supplicants. 

e¢ Cisco IOS routers running Cisco IOS Software, Release 12.3(8)T with security. 
e Cisco VPN 3000 Concentrators 

e Cisco Secure ACS 

e Cisco Security Agent 


To enable NAC reporting on your network, you must ensure that the NAC-specific events are logged by 
the reporting devices, that those devices forward the events to MARS, and that the device is defined in 
the web interface as a reporting device or mitigation device. 


The following reports are available to support NAC: 
e Activity: Security Posture Not Up To Date - All Events 
e Activity: Security Posture Not Up To Date - Top Users 
e Activity: Security Posture Up To Date - Top Users 
e Activity: Security Posture Validation Failure - Top Users 
e Activity: Security Posture w/o Credentials - Top Hosts 


For information on configuring reporting devices and mitigation devices with NAC support, see Enable 
NAC-specific Messages, page 3-4. 
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Integrating MARS with 3-Party Applications 


MARS provides multiple integration methods with 3"¢-party applications. The following topics describe 
how to integrate using these methods: 


e Forwarding Alert Data to 3rd-Party Syslog and SNMP Servers, page 2-43 
e MARS MIB Format, page 2-43 
e Relaying Syslog Messages from 3rd-Party Syslog Servers, page 2-44 


Forwarding Alert Data to 3-Party Syslog and SNMP Servers 


You can forward alert data from MARS to third-party syslog and SNMP servers. The data is forwarded 
on a per rule basis. In other words, you must configure those rules for which you want to forward alert 
data to include either SNMP, syslog, or both as a notification methods. When a rule fires, the 
notifications will be sent in the selected formats to the specified recipients, which should be the desired 
servers in the case of SNMP and syslog. 


For more information on configuring notification methods for a rule, see Setting Alerts, page 21-23. To 
learn more about the SNMP MIB format sent by MARS, see MARS MIB Format, page 2-43. 


MARS MIB Format 


The MARS management information base (MIB) is defined for all MARS releases. The SNMP 
notification contains the same content as the syslog generated by MARS. 


The MARS MIB definition is as follows: 


enterprises. 16686.1.0 string “MARS-1-101” 
enterprises. 16686.2.0 string “<alert_content>” 


The MARS private enterprise number is 16686 and <alert_content> is defined as follows: 
<<priorityInfo>> <current_time> @MARS-1-101: Rule <ruleid> (<rulename>) fired and caused 


<color> Incident <incidentId>, starting from <starttime> to <endtime>. 


In the following example of the SNMP notification output, 10.1.1.1 is the IP address of the MARS 
Appliance: 


SNMPv2-SMI::enterprises.16686 10.1.1.1 SNMPv2-SMI::enterprises.16686.1.0 "MARS-1-101" 
SNMPv2-SMI::enterprises.16686.2.0 "<34>Mon Apr 28 20:11:43 2003 %MARS-1-101: Rule 45513 
(Nimda Attack) fired and caused red Incident 12265001, starting from Mon Apr 28 19:58:47 
2003 to Mon Apr 28 20:11:21 2003." 


Note 


Notifications are sent only from the Local Controller. 
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Relaying Syslog Messages from 3rd-Party Syslog Servers 


You can rapidly deploy MARS by forwarding messages from existing syslog-ng or Kiwi syslog servers. 
This feature eliminates the network and device changes required to insert MARS into an operational 
network. You are no longer required to configure each network device to publish its syslog messages 
directly to MARS, which saves time, avoids device change approval processes, preserves packet 
processing performance of the network devices, and ensures daily network operations proceed without 
interruption. This relay feature also allows the correlation and inspection of syslog messages from 
reporting devices, such as those on the DMZ, for which corporate policies might prohibit the existence 
of or connection to configuration information. 


If your network devices already publish syslog messages to syslog-ng or Kiwi syslog servers, you can 
configure those servers to forward messages to the MARS Appliance and identify the syslog servers in 
MARS. Currently, MARS parses the syslog messages generated by the following devices: Cisco PIX, 
Cisco IOS, Cisco CatOS, Cisco ICS, Cisco ASA, Cisco FWSM, Cisco VPN 3000, Cisco Secure ACS, 
Snort IDS, Juniper/Netscreen firewalls, Solaris, Linux, and Microsoft Internet Information Server (ISS), 
Microsoft Windows running the SNARE agent. For other devices, you can define custom log parsers. 


The MARS Appliance can begin processing and storing the events while you define the reporting devices 
using the MARS user interface. You are still required to define the reporting device by IP address and 
device type in MARS to ensure proper event correlation; however, you are not required to configure 
device to publish syslog messages directly to MARS. 


To configure MARS to work with a syslog relay server, perform the following tasks: 


1. 


Configure the syslog relay server to forward correctly formatted messages to MARS. See Configure 
Syslog-ng Server to Forward Events to MARS, page 2-44 or Configure Kiwi Syslog Server to 
Forward Events to MARS, page 2-45. 


Identify the MARS Appliance as a forward target. 


Add the syslog relay server to the MARS user interface. See Add Syslog Relay Server to MARS, 
page 2-45. 


Add the reporting devices monitored by the syslog relay server to the MARS user interface. See Add 
Devices Monitored by Syslog Relay Server, page 2-46. 


Configure Syslog-ng Server to Forward Events to MARS 


We recommend the following settings in the configuration options of the syslog-ng.conf file to ensure 
good integration of syslog-ng with MARS: 


options { long_hostnames(off); use_dns(0); keep_hostname(yes); }; 


where 


The long_hostnames(off) setting conforms to RFC 3164, which recommends that the HOSTNAME 
does not contain domain name. 


The use_dns(0) setting ensures that the IP address is used in HOSTNAME rather than the 
hostnames. 


The keep_hostname(yes) setting preserves the original sending device’s HOSTNAME even when it 
is relayed more than once. 


In addition to configuring the message format, you must specify that the MARS Appliance is a 
destination loghost on UDP port 514. The following lines must appear in the syslog-ng.conf file: 


destination loghost { udp("JP address of MARS Appliance" port(514)); }; 


log { source(src); destination(loghost); }; 
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log { source(net); destination(loghost); }; 


Configure Kiwi Syslog Server to Forward Events to MARS 


Step 1 
Step 2 
Step 3 
Step 4 


Step 5 


Step 6 


We recommend the following settings in the configuration options of the Kiwi Syslog Daemon to ensure 
good integration of Kiwi with MARS: 


Expand the File > Setup > Rules > Actions tree. 
Right on Actions and click Add an Action. 
Enter a name for the action, such as “Forward to pncop”. 
For the following fields, enter the following values: 
e Destination IP address or hostname — Enter the IP address of the MARS Appliance. 
e Protocol — UDP 
e New Facility — No Change 
e New Level — No Change 
e Port — 514 


e Send with RFC 3164 header information — Selected if the syslog server receives syslog 
messages directly from the source devices only. Clear if the syslog server also receives syslog 
messages from relays. Do not configure mixed relays. 


This additional header is necessary for the supported device types that do not have HOSTNAME 
in the syslog messages; thereby allowing MARS to correctly identify the original sending 
device. However, this option cannot be used on a Kiwi relay of relay. To support a Kiwi relay 
of relay in MARS, the first relay must have this option selected and must receive syslog 
messages only from the source devices, and all other relays must have this option cleared and 
must only receive syslog messages from other Kiwi relays, not directly from devices. 


e Retain the original source address of the message — Cleared. 


If you are using SNARE agents, click Setup > Modifiers and clear “Replace non printable characters 
with <ASCII value>” 


If this value is selected, tabs appear as <009> in the Windows event logs, which prevents MARS from 
parsing the events correctly. 


Save your changes. 


Add Syslog Relay Server to MARS 


Step 1 
Step 2 


In addition to representing each of the potential reporting devices, you must define the syslog relay 
server so that MARS knows for which messages it should attempt to discover the true reporting device. 
To add a syslog relay server, you must add it as a security software application running on a host. 


To add a syslog relay server, follow these steps: 


Select Admin > System Setup > Security and Monitor Devices > Add. 
Do one of the following: 


e Select Add SW Security apps on a new host from the Device Type list, and continue with Step 3 
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Step 3 


Step 4 


Step 5 
Step 6 
Step7 
Step 8 


Step 9 


Step 10 


Step 11 


e Select Add SW security apps on existing host from the Device Type list. Select the device to which 
you want to add the software application and click Add. Continue with Step 6. 


Specify values for the following fields: 


e¢ Device Name — Enter the hostname of the syslog relay server. MARS maps this name to the 
reporting IP address. This name is used in topology maps, queries, and as the primary management 
station in the Security and Monitoring Device list. 


e Reporting IP — Enter the IP address of the interface in the syslog relay server from which MARS 
will receive syslog messages. 


This address represents the physical IP address of the syslog relay server. To learn more about the 
reporting IP address, its role, and dependencies, see Understanding Access IP, Reporting IP, and 
Interface Settings, page 2-8. 


Under Enter interface information, enter the interface name, IP address, and netmask value of the 
interface in the syslog relay server from which syslog messages will be received. 


This address represents the physical IP address of the syslog relay server. To learn more about the 
interface settings, its role, and dependencies, see Understanding Access IP, Reporting IP, and Interface 
Settings, page 2-8. 


Click Apply to save these settings. 

Click Next to access the Reporting Applications tab. 

Select Generic Syslog Relay ANY from the Select Application list, and click Add. 
Click Submit to add this application to the host. 

Result: Generic Syslog Relay ANY appears in the Device Type list. 


Click the Vulnerability Assessment Info link to define the host information that MARS uses to 
determine false positive attacks against this host. Continue with Define Vulnerability Assessment 
Information, page 10-11. 


Click Done to save the changes. 
Result: The host appears in the Security and Monitoring Information list. 


To activate the device, click Activate. 


Add Devices Monitored by Syslog Relay Server 


While you do not have to configure each reporting device to forward syslog messages to the MARS 
Appliance, you must define the device to MARS so that when it parses the syslog messages forwarded 
by the relay server, then it is able to match the true reporting IP address to that of a known reporting 
device type. By knowing the reporting device type, MARS can correctly parse the events. 


The process for adding these reporting devices is the same as if there were no syslog relay server except 
that you do not configure the reporting device to forward events to the MARS Appliance. In the MARS 
web interface, you should still configure the reporting devices so that MARS can discover their settings 
and to perform any mitigation operations. 
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This chapter describes how to bootstrap routers and switches and add those reporting devices and 
mitigation devices to MARS. It also describes how to configure NetFlow, NAC’s EAP over UDP and 
802.1x logging, and the Layer 2 (L2) mitigation features of switches. 


Routers and switches provide MARS with data about traffic flows and the network topology, including 
address translations, endpoint devices, connected networks, and accepted and rejected sessions. Routers 
and switches also support modules that enable features common to specialty security appliances, such 
as firewalls and intrusion detection or prevention systems (IDS/IPS). This chapter does not describe how 
to enable the features on routers and switches that enable the modules or how to configure these modules 
for use by MARS. Such discussions are provided in Configuring Firewall Devices, page 4-1, and 
Configuring Network-based IDS and IPS Devices, page 6-1. 


This chapter explains how to bootstrap and add the following router and switch devices to MARS: 
e Cisco Router Devices, page 3-1 
e Cisco Switch Devices, page 3-9 
e Extreme ExtremeWare 6.x, page 3-17 


e Generic Router Device, page 3-18 


Cisco Router Devices 


To configure Cisco routers running Cisco IOS Software Release 12.2 to communicate with a MARS 
Appliance, you must perform three tasks: 


e Enable Administrative Access to Devices Running Cisco IOS 12.2, page 3-1 
e Configure the Device Running Cisco IOS 12.2 to Generate Required Data, page 3-3 
e Add and Configure a Cisco Router in MARS, page 3-6 


Enable Administrative Access to Devices Running Cisco IOS 12.2 


You must enable administrative access by the MARS Appliance to any Cisco routers or switches running 
Cisco IOS Software release 12.2 or later. The type of access that you must enable depends on whether 
modules are installed in your Cisco router or switch and the role of the device in your network. MARS 
uses this administrative access to discover the device’s configuration and, at times, to make changes to 
the device’s running configuration. For information on selecting an administrative access method, see 

Selecting the Access Type, page 2-10. 
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Before you add a Cisco router to MARS, make sure that you have enabled SNMP, Telnet, SSH, or FTP 
access to the router. The following sections provide guidance on configuring each supported access 
method: 


e Enable SNMP Administrative Access, page 3-2 

e Enable Telnet Administrative Access, page 3-2 

e Enable SSH Administrative Access, page 3-2 

e Enable FTP-based Administrative Access, page 3-2 


Enable SNMP Administrative Access 
To enable configuration discovery using SNMP access to the Cisco router or switch, refer to your device 
documentation or the following URL: 


http://cisco.com/en/US/products/sw/iosswrel/ps1835/products_configuration_guide_chapter09 186 
2008030c762.html#wp 1001217 


Enable Telnet Administrative Access 
To enable configuration discovery using Telnet access to the Cisco router or switch, refer to your device 
documentation or the following URL: 


http://cisco.com/en/US/products/sw/iosswrel/ps 18 18/products_configuration_example09 186a0080 
204528.shtml 


Enable SSH Administrative Access 


To enable configuration discovery using SSH access to the Cisco router or switch, refer to your device 
documentation or the following URL: 


http://cisco.com/en/US/products/sw/iosswrel/ps1834/products_feature_guide09186a008007fed9.ht 
ml 


Enable FTP-based Administrative Access 


To enable configuration discovery using FTP access, you must place a copy the Cisco router’s or switch’s 
configuration file on an FTP server to which the MARS Appliance has access. This FTP server must have 
user authentication enabled. 


wy 


Note TFTP is not supported. You must use an FTP server. 


You must copy the running configuration from the Cisco router or switch. For information on copying 
the running configuration, refer to your device documentation or the following URL: 


http://www.cisco.com/en/US/products/sw/iosswrel/ps 1835/products_tech_note09186a008020260d 
shtml 
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Configure the Device Running Cisco IOS 12.2 to Generate Required Data 


Cisco routers and switches that are running Cisco IOS Software release 12.2 can be configured to 
provide different types of data to MARS: 


e Syslog messages. The syslog messages provide information about activities on the network, 
including accepted and rejected sessions. 


e SNMP traffic. SNMP RO community strings support the discovery of your network’s topology. 


e NAC-specific data. NAC logs events that are specific to its configuration, including Extensible 
Authentication Protocol (EAP) over UDP messages and 802.1x accounting messages. 


e Access lists or NAT statements. You must enable SSH or Telnet access if the configuration on the 
Cisco router or swtich includes access lists or NAT statements. 


e Spanning tree messages (Switch only). You must have STP (spanning tree protocol) configured 
correctly on the switches to enable L2 discovery and mitigation. STP provides MARS with access 
to the L2 MIB, which is required to identify L2 re-routes of traffic and to perform L2 mitigation. 
MARS also uses the MIB to identify trunks to other switches, which are used to populate VLAN 
information used in L2 path calculations. STP, which is enabled by default on Cisco Switches, 
should remain enabled, as it is required for L2 mitigation. 


The following topics describe how to configure these settings: 
e Enable Syslog Messages, page 3-3 
e Enable SNMP RO Strings, page 3-3 
e Enable NAC-specific Messages, page 3-4 
e Enable L2 Discovery Messages, page 3-12 
e Enable SDEE for IOS IPS Software, page 3-6 


Enable Syslog Messages 


To send syslog messages to the MARS Appliance from a device running Cisco IOS Software Release 
12.2, follow these steps: 


Step 1 Log in to the Cisco IOS device with enabled password. 
Step2 Enter the commands: 


Router (config) #logging source-interface <interface name> 
Router (config) #logging trap <logging level desired> 
Router (config) #logging <IP address of MARS Appliance> 


Enable SNMP RO Strings 


To enable SNMP RO strings for topology discovery on the Cisco IOS device, you must enable the SNMP 
server, define the RO community, and then direct the SNMP server to forward SNMP traps to the MARS 
Appliance. 


To configure the SNMP RO string settings, follow these steps: 


Step 1 Enter configuration mode: 
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Step 2 


Router> enable 
Password: <password> 
Router# 


Enter the configure terminal command to enter configuration mode: 


Router# configure terminal 
Enter configuration commands, one per line. End with CNTL/Z. 
Router (config) # 


Set the SNMP read community string as follows: 


Router (config)# snmp-server community <read community> RO <ACL name if required> 


This information is required to retrieve the MAC addresses and associated L2 information. 


Set the SNMP write community string as follows: 


Router (config) # snmp-server community <write community> RW 


Enable NAC-specific Messages 


Cisco Routers 


Cisco routers and switches that are running Cisco IOS Software release 12.2 or CatOS can enable 
network Admission Control (NAC) specific data. This data includes: 


e Client logs. These logs relate the activities of the client software. 


e RADIUS server logs. These logs relate the authorization communications between clients and the 
posture validation servers. 


¢ Network access device logs. These logs relate connection attempts by clients and final 
authorizations provided by the AAA server enforcing the NAC policies. 


For more information on the events that are logged as part of NAC, see the Monitoring and Reporting 
Tool Integration into Network Admission Control white paper at the following URL: 


http://www.cisco.com/en/US/netsol/ns617/networking_solutions_white_paperO900aecd801dee49.s 
html 


This section contains the following two topics, which address the NAC configuration settings specific to 
each device type: 


e Cisco Routers, page 3-4 
e Cisco Switches, page 3-5 


To configure the NAC Phase I data on a Cisco router to work with MARS, you must allow EAP over 
UDP and allow an IP address in the AAA station-id field of the packets. In addition, you must enable 
logging of these events, which are published as syslog messages. 

To enable the NAC-specific data on a Cisco router, enter the following commands: 


Router (config) #eou allow ip-station-id 
Router (config) #eou logging 
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For more information on these commands and related commands, see the Network Admission Control 
feature document at the following URL: 


http://www.cisco.com/univercd/cc/td/doc/product/software/ios 123/123newft/123t/123t_8/gt_nac.h 
tm 


NAC Phase II enables Cisco switches to act as network access devices. To support this new feature, you 
must configure the Cisco switch to initiate 802.1x authentication when the link state changes from down 
to up and periodically if the port remains up but unauthenticated. NAC requires that hosts use 802.1x 
supplicants, or clients, to authenticate to the Cisco Secure ACS server before gaining access to network 
services. Enabling the 802.1x messages on your network helps you troubleshoot supplicant failures 
becauise connection attempts are logged, which you can analyze. 


Configuring the Cisco switch to act as proxy between the Cisco Secure ACS server and the 802.1x 
supplicants is a multi-step process. First, the e switch must be defined as a AAA client (RADIUS) in the 
Cisco Secure ACS server. For information on defining a AAA client, see Define AAA Clients, page 
14-5. Second, the switch must be configured to use aa RADIUS server. Then, you must enable the 
following features on each interface installed in the switch: 


e 802.1X port-based authentication. The device requests the identity of the client and begins 
relaying authentication messages between the client and the authentication server. Each client 
attempting to access the network is uniquely identified by the system by using the client’s MAC 
address. 


e 802.1x reauthentication. The device re-authenticates the supplicants after the reauthentication 
timeout value is reached, which is 3600 seconds by default. 


e 802.1x accounting. The device logs authentication successes and failures, as well as link down 
events and users logging off. The switch publishes these audit records to the Cisco Secure ACS 
server for logging. 


¢ DHCP snooping. The device filters DHCP requests, safeguarding against spoof attacks. This 
feature ensures that MARS receives reliable data and identifies the port number of the 802.1x 
supplicant. 


The following URLs detail how to configure these features: 


Dot1x and Radius Sever 


IOS Software: 
http://www.cisco.com/univercd/cc/td/doc/product/lan/cat3750/12225sec/3750scg/sw8021x.htm 


CatOS Software: 
http://www.cisco.com/univercd/cc/td/doc/product/lan/cat6000/sw_8_4/confg_gd/8021x.htm 


DHCP Snooping 


IOS Software: 
http://www.cisco.com/univercd/cc/td/doc/product/lan/cat3750/12225sec/3750scg/swdhcp82.htm 


CatOS Software: 
http://www.cisco.com/univercd/cc/td/doc/product/lan/cat6000/sw_8_4/confg_gd/dhcp.htm 


After you configure the switch to act as proxy and it is defined as a AAA client in Cisco Secure ACS, 
you must ensure that the authentication messages are sent to the MARS Appliance. For 802.1x 
accounting records, you must ensure that the audit records are written to the RADIUS log on the 
Cisco Secure ACS server. To configure these settings, refer toConfigure Cisco Secure ACS to Generate 
Logs, page 14-3. 
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Enable SDEE for IOS IPS Software 


Before you enable SDEE, you must enable either Telnet or SSH as the access type for configuration 
discovery on a Cisco IOS device. You must also enable SDEE on the device that supports the IOS IPS 
software feature. SDEE is used to publish events to MARS about signatures that have fired. 


To enable SDEE protocol on the Cisco IOS device that supports IOS IPS, follow these steps: 


Step 1 Log in to the Cisco IOS device using the enable password. 


Step2 Enter the following commands to enable MARS to retrieve events from the IOS IPS software: 


Router(config)#ip http secure-server 
Router (config)#ip ips notify sdee 
Router (config)#ip sdee subscriptions 3 
Router (config) #ip sdee events 1000 
Router (config)#no ip ips notify log 


& 


Note The “no ips notify log” causes the IOS IPS software to stop sending IPS events over syslog. 


Add and Configure a Cisco Router in MARS 


Cisco routers provide data about the network and its activities in the form of syslog messages and SNMP 
RO MIBs. In addition, MARS can discover settings, such as network address translations, attached 
networks, and active access rules, that improve the accuracy of false positive identification, attack path 
analysis, and L3 network discovery. 


To add a Cisco router running Cisco IOS 12.2 or later, follow these steps: 


Step1 Select Admin > System Setup > Security and Monitor Devices > Add. 
Step2 Select Cisco IOS 12.2 from the Device Type list. 
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Step 4 


Step 5 


Step 6 


Step 7 


Cisco Router Devices Mi 


De 


> *Device Name: [ | 


> Access IP: lI l{ | 


> Reporting IP: 


> *Access Type: 


Login: 

Password: 

Enable Password: —— 
Config Path: [ 

File Name: CF] 
SNMP RO 


Community: 


=> Monitor Resource NO 
Usage: 


143635 


Back Discover Next 


Enter the name of the device in the Device Name field. 


MARS maps this name to the reporting IP address. This name is used in topology maps, queries, and in 
the Security and Monitoring Device list. For devices that support the discovery operation, such as routers 
and firewalls, MARS renames this field’s value to match the name discovered in the device 
configuration, which typically uses the hostname.domain format. For devices that cannot be discovered, 
such as Windows and Linux hosts and host applications, MARS uses the provided value. 


(Optional) To enable MARS to discover settings from this device, enter the administrative IP address in 
the Access IP field. 


To learn more about the access IP address, its role, and dependencies, see Understanding Access IP, 
Reporting IP, and Interface Settings, page 2-8. 


Enter the IP address of the interface that publishes syslog messages, SNMP notifications, NetFlow 
MIBs, or any combination of the three, in the Reporting IP field. 


To learn more about the reporting IP address, its role, and dependencies, see Understanding Access IP, 
Reporting IP, and Interface Settings, page 2-8. 


If you entered an address in the Access IP field, select SNMP, TELNET, SSH, or FTP from the Access 
Type list, and continue with the procedure that matches your selection: 


e Configure SNMP Access for Devices in MARS, page 2-11 
e Configure Telnet Access for Devices in MARS, page 2-11 
e Configure SSH Access for Devices in MARS, page 2-12 
e Configure FTP Access for Devices in MARS, page 2-12 
For more information on determining the access type, see Selecting the Access Type, page 2-10. 


(Optional) To enable MARS to retrieve MIB objects for this reporting device, enter the device’s 
read-only community string in the SNMP RO Community field. 
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Before you can specify the SNMP RO string, you must define an access IP address. MARS uses the 
SNMP RO string to read MIBs related to a reporting device’s CPU usage, network usage, and device 
anomaly data and to discover device and network settings. 


Step8 (Optional) To enable MARS to monitor this device for anomalous resource usage, select Yes from the 
Monitor Resource Usage list. 


Result: MARS monitors the device for anomalous consumption of resources, such as memory and CPU. 
If anomalies are detected, MARS generates an incident. Resource utilization statistics are also used to 
generate reports. For more information, see Configuring Resource Usage Data, page 2-41. 


Step9 (Optional) If this router has the IOS IPS feature and SDEE access enabled and you have configured the 
router to accept HTTPS connections from the MARS Appliance, click Add IPS to provide the username 
and password required to pull SDEE events. 


Note IOS IPS does not refer to an IPS module. It refers to a software feature in the IOS software. The IOS IPS 
feature is required to enable the DTM functionality in MARS. See Technology Preview: Configuring 
Distributed Threat Mitigation with Intrusion Prevention System in Cisco Security MARS, page 1 for 
more information. 


Result: The IOS IPS Information page appears. 


10S IPS Information 


Reporting IP: 192.168.20.1 


Port: 


wr 


oO 
N 
| Test Connectivity | [ Cancel | Submit | 9 


a. Enter the username that has HTTPS access to this device in the User Name field. 
b. Enter the corresponding password in the Password field. 
c. In the Port field, verify the port used for SDEE communications with this device. 


MARS pulls data using SDEE over HTTPS. The default port number for HTTPS/SDEE is 443. This 
access allows MARS to retrieve XML files that contain the events generated by the IOS IPS feature. 


Result: MARS can query the router for SDEE events. 


Step10 (Optional) If you defined an access IP and selected and configured an access type, click Discover to 
determine the device settings, including the IOS IPS settings. 


Result: If the username and password are correct and the MARS Appliance is configured as an 
administrative host for the device, the “Discovery is done.” dialog box appears when the discovery 
operation completes. Otherwise, an error message appears. After the initial pull, the MARS Appliance 
pulls based on the schedule that you define. For more information, see Scheduling Topology Updates, 
page 2-39. 


Step 11 To add this device to the MARS database, click Submit. 
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Result: The submit operation records the changes in the database tables. However, it does not load the 
changes into working memory of the MARS Appliance. The activate operation loads submitted changes 
into working memory. 


Click Activate. 


Result: MARS begins to sessionize events generated by this device and evaluate those events using the 
defined inspection and drop rules. Any events published by the device to MARS before activation can 
be queried using the reporting IP address of the device as a match criterion. For more information on the 
activate action, see Activate the Reporting and Mitigation Devices, page 2-27. 


Cisco Switch Devices 


You can manage Cisco switches that run either CatOS or Cisco IOS Software Release 12.2 or later. The 
configuration of the switch varies between these two operating system, as does the addition of the device 
in MARS. Adding a Cisco switch involves three steps: 


1. Configure the switch to enable MARS to discover the its settings. 
2. Configure the switch to generate the data required by MARS. 

3. Add and configure the switch in MARS. 

4. Add modules to the switch. 


To prepare a Cisco switch running Cisco IOS Software Release 12.2 or later, refer to the following 
procedures: 


e Enable Administrative Access to Devices Running Cisco IOS 12.2, page 3-1 

e Configure the Device Running Cisco IOS 12.2 to Generate Required Data, page 3-3 
To prepare a Cisco switch running CatOS, refer to the following procedures: 

e Enable Communications Between Devices Running CatOS and MARS, page 3-9 

e Configure the Device Running CatOS to Generate Required Data, page 3-11 


Adding a Cisco switch running to MARS has two distinct steps. First, you add the base module of the 
switch, providing administrative access to that device. Second, you add any modules that are running in 
the switch. For instructions on performing these two steps, refer to the following topics: 


e Add and Configure a Cisco Switch in MARS, page 3-13 
e Adding Modules to a Cisco Switch, page 3-14 


Enable Communications Between Devices Running CatOS and MARS 


Before you add a Cisco switch running CatOS to MARS, make sure that you have enabled SNMP, Telnet, 
SSH, or FTP access to the swtich. First, you must configure the MARS Appliance as an IP address that 
is permited to access the switch. 


For information on permitting IP addresses and specifying the access type, see the following URL: 


http://www.cisco.com/univercd/cc/td/doc/product/lan/cat6000/sw_8_4/confg_gd/ip_perm.htm#wp 1019 
819 


Next, you must ensure that your switch is configured to enable the correct access method. The following 
sections provide guidance on configuring each supported access method: 
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e Enable SNMP Administrative Access, page 3-10 

e Enable Telnet Administrative Access, page 3-10 

e Enable SSH Administrative Access, page 3-10 

e Enable FTP-based Administrative Access, page 3-10 


Enable SNMP Administrative Access 


To enable configuration discovery using SNMP access to the Cisco switch, refer to your device 
documentation or the following URL: 


IP Access 


http://www.cisco.com/univercd/cc/td/doc/product/lan/cat6000/sw_8_4/confg_gd/ip_perm.htm#wp 
1019819 


Configure SNMP 
http://www.cisco.com/univercd/cc/td/doc/product/lan/cat6000/sw_8_4/confg_gd/snmp.htm 
Enable Telnet Administrative Access 


To enable configuration discovery using Telnet access to the Cisco switch, refer to your device 
documentation or the following URL: 


IP Access 


http://www.cisco.com/univercd/cc/td/doc/product/lan/cat6000/sw_8_4/confg_gd/ip_perm.htm#wp 
1019819 


Enable SSH Administrative Access 


To enable configuration discovery using SSH access to the Cisco router or switch, refer to your device 
documentation or the following URL: 


IP Access 


http://www.cisco.com/univercd/cc/td/doc/product/lan/cat6000/sw_8_4/confg_gd/ip_perm.htm#wp 
1019819 


Enable FTP-based Administrative Access 


To enable configuration discovery using FTP access, you must place a copy the Cisco router’s or switch’s 
configuration file on an FTP server to which the MARS Appliance has access. This FTP server must have 
user authentication enabled. 


wy 


Note TFTP is not supported. You must use an FTP server. 


You must copy the running configuration from the Cisco switch. For information on copying the running 
configuration, refer to your device documentation or the following URL: 


http://www.cisco.com/univercd/cc/td/doc/product/lan/cat6000/sw_8_4/confg_gd/admin.htm#wp10 
40556 
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Configure the Device Running CatOS to Generate Required Data 


You can configure the following message types: 
e SNMP RO strings 
e NAC messages (802.1x) 
e L2 discover settings 
e Syslog message 
For information on configuring these settings, refer to the following topics: 
e Enable SNMP RO Strings on CatOS, page 3-11 
e Enable NAC-specific Messages, page 3-4 
e Enable L2 Discovery Messages, page 3-12 
e Enable Syslog Messages on CatOS, page 3-11 


Enable SNMP RO Strings on CatOS 


If the supervisor SNMP server is not configured, you must perform this procedure. 


To configure the supervisor SNMP server and enabled SNMP traps on the Catalyst switch, follow these 
steps: 


Step 1 Enter configuration mode: 


switch> enable 
Enter password: <password> 
switch> (enable) 


Step2 Set the SNMP read community string as follows: 


switch> (enable) set snmp community read-only <read community> 


Step3 Set the SNMP write community string as follows: 


switch> (enable) set snmp community read-write <write community> 
switch> (enable) set snmp community read-write-all <write community> 


Step4 = Tocollect RMON Ethernet statistics, RMON data collection must be enabled in the CatOS agent (this is 
not required in Native IOS). To enable RMON collection, enter the following: 


switch> (enable) set snmp rmon enable 


Step5 Exit configuration mode as follows: 


switch> (enable) exit 


Enable Syslog Messages on CatOS 


To configure a Cisco switch running CatOS to send syslog information to MARS, follow these steps: 


Step 1 To enable the syslog server on the switch, enter: 


set logging server enable 
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Step 2 


Step 3 


Enable L2 Discovery Messages 


To identify the MARS Appliance as a destination for syslog messages, enter the following command: 


set logging server <IP address of MARS Appliance> 


The remaining commands tell the switch what kinds of logging information to provide and at what level. 
The commands in the following example can be changed to suit your requirements. 


se 
se 
se 
se 
se 
se 
se 
se 
se 
se 
se 
se 
se 
se 
se 
se 
se 
se 
se 
se 
se 
se 
se 
se 
se 
se 
se 
se 
se 


Ct eh cer oer oot ch ocr cer og er ctr oer ct oP oer oe och ct oct cr ot ctr ct 


ct 


GE Gt 


logging 
logging 
logging 
logging 
logging 
logging 
logging 
logging 
logging 
logging 
logging 
logging 
logging 
logging 
logging 
logging 
logging 
logging 
logging 
logging 
logging 
logging 
logging 
logging 
logging 
logging 
logging 
logging 
logging 


level 
level 
level 
level 
level 
level 
level 
level 
level 
level 
level 
level 
level 
level 
level 
level 
level 
level 
level 
level 
level 
level 
level 
level 
level 


cdp 7 default 
mcast 7 default 
dtp 7 default 
dvlan 7 default 
earl 7 default 
fddi 7 default 

ip 7 default 
pruning 7 default 
snmp 7 default 
spantree 7 default 
sys 7 default 

tac 7 default 

tcp 7 default 
telnet 7 default 
tftp 7 default 

vtp 7 default 

vmps 7 default 
kernel 7 default 
filesys 7 default 
drip 7 default 
pagp 7 default 
mgmt 7 default 

mls 7 default 
protfilt 7 default 
security 7 default 


server facility SYSLOG 
server severity 7 
buffer 250 

timestamp enable 


To enable L2 discovery on your Cisco switches, you must enable the spanning tree protocol (STP) and 
provide the SNMP RO community string. All L 2 devices must support SNMP STP MIB (IETF RFC 
1493). The discovered information includes interfaces, Layer 3 (L3) routes, L2 spanning trees, L2 


forwarding tables, MAC addresses, and so on. 


Note 


STP is enabled by default on all Cisco switches. Therefore, unless you have altered this setting, no 
changes are necessary. 


For more information on configuring STP, select Spanning Tree Protocol in the View Documents by 
topics list at the following URLs: 


http://www.cisco.com/en/US/partner/products/hw/switches/ps708/prod_configuration_examples_list.ht 


ml 


http://www.cisco.com/univercd/cc/td/doc/product/lan/cat6000/sw_8_4/confg_gd/spantree.htm 
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Add and Configure a Cisco Switch in MARS 


Step 1 
Step 2 


Step 3 


Step 4 


Step 5 


Step 6 


Step7 


Step 8 


MARS monitors Cisco switches running either CatOS or Cisco IOS 12.2. 


To add the configuration information that MARS uses to monitor a Cisco switch running Cisco IOS 12.2 
or later, follow these steps: 


Select Admin > System Setup > Security and Monitor Devices > Add. 
Do one of the following: 


e If the switch is running any version of CatOS, select Cisco Switch-CatOS ANY from the Device 
Type list. 


e Ifthe switch is running Cisco IOS 12.2 or later, select Cisco Switch-IOS 12.2 from the Device Type 
list. 


Enter the name of the device in the Device Name field. 


MARS maps this name to the reporting IP address. This name is used in topology maps, queries, and in 
the Security and Monitoring Device list. For devices that support the discovery operation, such as routers 
and firewalls, MARS renames this field’s value to match the name discovered in the device 
configuration, which typically uses the hostname.domain format. For devices that cannot be discovered, 
such as Windows and Linux hosts and host applications, MARS uses the provided value. 


(Optional) To enable MARS to discover settings from this device, enter the administrative IP address in 
the Access IP field. 


To learn more about the access IP address, its role, and dependencies, see Understanding Access IP, 
Reporting IP, and Interface Settings, page 2-8. 


Enter the IP address of the interface that publishes syslog messages, SNMP notifications, NetFlow 
MIBs, or any combination of the three, in the Reporting IP field. 


To learn more about the reporting IP address, its role, and dependencies, see Understanding Access IP, 
Reporting IP, and Interface Settings, page 2-8. 


If you entered an address in the Access IP field, select SNMP, TELNET, SSH, or FTP from the Access 
Type list, and continue with the procedure that matches your selection: 


e Configure SNMP Access for Devices in MARS, page 2-11 
e Configure Telnet Access for Devices in MARS, page 2-11 
e Configure SSH Access for Devices in MARS, page 2-12 
e Configure FTP Access for Devices in MARS, page 2-12 
For more information on determining the access type, see Selecting the Access Type, page 2-10. 


(Optional) To enable MARS to retrieve MIB objects for this reporting device, enter the device’s 
read-only community string in the SNMP RO Community field. 


Before you can specify the SNMP RO string, you must define an access IP address. MARS uses the 
SNMP RO string to read MIBs related to a reporting device’s CPU usage, network usage, and device 
anomaly data and to discover device and network settings. 


(Optional) To enable MARS to monitor this device for anomalous resource usage, select Yes from the 
Monitor Resource Usage list. 


Result: MARS monitors the device for anomalous consumption of resources, such as memory and CPU. 
If anomalies are detected, MARS generates an incident. Resource utilization statistics are also used to 
generate reports. For more information, see Configuring Resource Usage Data, page 2-41. 
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Step 9 


Step 10 


Step 11 


(Optional) If you defined an access IP and selected and configured an access type, click Discover to 
determine the device settings 


Result: If the username and password are correct and the MARS Appliance is configured as an 
administrative host for the device, the “Discovery is done.” dialog box appears when the discovery 
operation completes. Otherwise, an error message appears. After the initial pull, the MARS Appliance 
pulls based on the schedule that you define. For more information, see Scheduling Topology Updates, 
page 2-39. 


To add this device to the MARS database, click Submit. 


Result: The submit operation records the changes in the database tables. However, it does not load the 
changes into working memory of the MARS Appliance. The activate operation loads submitted changes 
into working memory. 


Click Activate. 


Result: MARS begins to sessionize events generated by this device and evaluate those events using the 
defined inspection and drop rules. Any events published by the device to MARS before activation can 
be queried using the reporting IP address of the device as a match criterion. For more information on the 
activate action, see Activate the Reporting and Mitigation Devices, page 2-27. 


After submitting, you can add modules. See Adding Modules to a Cisco Switch, page 3-14. 


Adding Modules to a Cisco Switch 


In MARS, you can represent, discover, and monitor modules that are installed in Cisco switches. These 
modules perform special purpose security functions for the switch, such as firewall or intrusion detection 
and prevention. MARS recognizes the following switch modules and versions: 


e Cisco FWSM 1.1, 2.2, and 2.3 
e Cisco IDS 3.1 and 4.0 

e Cisco IPS 5.x 

e Cisco IOS 12.2 


To add a module, you must first add the base module, which is the Cisco switch. After the base module 
is defined in the web interface, you can discover the modules that are installed in the switch (click Add 
Available Module) or add them manually (click Add Module). 


For instructions on adding and configuring a firewall services module (FWSM), see Cisco Firewall 
Devices (PIX, ASA, and FWSM), page 4-1. 


For instructions on adding and configuring an intrusion detection or prevention services module IDSM 
or IPSM), see Cisco IPS Modules, page 6-9. 


This section contains the following topics: 
e Add Available Modules, page 3-14 
e Add Cisco IOS 12.2 Modules Manually, page 3-15 


Add Available Modules 


When you perform a discovery operation on a base module, MARS lists the discovered modules. From 
this list, you can select the modules to monitor using MARS. 
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To add available modules, follow these steps: 


Click Add Available Module. 


Add Module | Edit Module I Remove Module | Add Available Module 
Module Name Module Type 


[- HQ-SW-1-msfc Cisco IOS 12.2 
[ HQ-SW-1-idsm Cisco IDS 3.1 


143216 


If modules are installed in the switch, a list of the modules appears. 
Select a module from the Select list. 

Click Add. 

Repeat for other modules. 


After you add the desired modules, verify the configuration information of each. For example, verify that 
the SNMP RO community string matches that defined for use by MARS. To verify these settings, select 
a module and click Edit Module. 


Basic guidance for editing these settings can be found in the topics that discuss manually adding these 
modules. See the following topics for more information: 


e Add Cisco IOS 12.2 Modules Manually, page 3-15 
e Cisco Firewall Devices (PIX, ASA, and FWSM), page 4-1 
e Cisco IPS Modules, page 6-9. 
To add these modules to the base module defined in the MARS database, click Submit. 


Result: The submit operation records the changes in the database tables. However, it does not load the 
changes into working memory of the MARS Appliance. The activate operation loads submitted changes 
into working memory. 


Click Activate. 


Result: MARS begins to sessionize events generated by this device and the selected modules and 
evaluate those events using the defined inspection and drop rules. Any events published by the device or 
its modules to MARS before activation can be queried using the reporting IP address of the device or 
module as a match criterion. For more information on the activate action, see Activate the Reporting and 
Mitigation Devices, page 2-27. 


Add Cisco 10S 12.2 Modules Manually 


Step 1 
Step 2 


To add a module manually, follow these steps: 


Click Add Module. 
Select Cisco IOS 12.2 from the Device Type list. 
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Step 3 


Step 4 


Step 5 


Step 6 


Step 7 


Step 8 


*Device Nam 
> Access IP: 
> Reporting IP: 


> *Access Type: 


Login: 

Password: 

Enable Password: 

Config Path: [SY 


File Name: | 


SNMP RO Community: 


> Monitor Resource NO -* 
Usage: 


143207 


Enter the name of the module in the Device Name field. 


MARS maps this name to the reporting IP address. This name is used in topology maps, queries, and in 
the Security and Monitoring Device list. For modules that support the discovery operation, such as router 
and firewall modules, MARS renames this field’s value to match the name discovered in the device 
configuration, which typically uses the hostname.domain format. 


(Optional) To enable MARS to discover settings from this device, enter the administrative IP address in 
the Access IP field. 


To learn more about the access IP address, its role, and dependencies, see Understanding Access IP, 
Reporting IP, and Interface Settings, page 2-8. 


Enter the IP address of the interface that publishes syslog messages, SNMP notifications, NetFlow 
MIBs, or any combination of the three, in the Reporting IP field. 


To learn more about the reporting IP address, its role, and dependencies, see Understanding Access IP, 
Reporting IP, and Interface Settings, page 2-8. 


If you entered an address in the Access IP field, select TELNET, SSH, or FTP from the Access Type 
list, and continue with the procedure that matches your selection: 


e Configure Telnet Access for Devices in MARS, page 2-11 
e Configure SSH Access for Devices in MARS, page 2-12 
e Configure FTP Access for Devices in MARS, page 2-12 
For more information on determining the access type, see Selecting the Access Type, page 2-10. 


(Optional) To enable MARS to retrieve MIB objects for this reporting device, enter the device’s 
read-only community string in the SNMP RO Community field. 


Before you can specify the SNMP RO string, you must define an access IP address. MARS uses the 
SNMP RO string to read MIBs related to a reporting device’s CPU usage, network usage, and device 
anomaly data and to discover device and network settings. 


(Optional) To enable MARS to monitor this device for anomalous resource usage, select Yes from the 
Monitor Resource Usage list. 
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Result: MARS monitors the module for anomalous consumption of resources, such as memory and CPU. 
If anomalies are detected, MARS generates an incident. Resource utilization statistics are also used to 
generate reports. For more information, see Configuring Resource Usage Data, page 2-41. 


(Optional) If you defined an access IP and selected and configured an access type, click Discover to 
determine the module settings. 


Result: If the username and password are correct and the MARS Appliance is configured as an 
administrative host for the module, the “Discovery is done.” dialog box appears when the discovery 
operation completes. Otherwise, an error message appears. After the initial pull, the MARS Appliance 
pulls based on the schedule that you define. For more information, see Scheduling Topology Updates, 
page 2-39. 


To add this module to the device in the MARS database, click Submit. 


Result: The submit operation records the changes in the database tables. However, it does not load the 
changes into working memory of the MARS Appliance. The activate operation loads submitted changes 
into working memory. 


Extreme ExtremeWare 6.x 


MARS can use Extreme ExtremeWare switches to enforce L2 mitigation. To configure MARS to 
communicate with an ExtremeWare switch, you must configure the switch to publish SNMP 
notifications to the MARS Appliance. In addition, you must add and configure the switch in the web 
interface. 


This section contains the following topics: 
e Configure ExtremeWare to Generate the Required Data, page 3-17 
e Add and Configure an Extreme Ware Switch in MARS, page 3-18 


Configure ExtremeWare to Generate the Required Data 


Step 1 


Step 2 


To bootstrap an ExtremeWare switch, you must configure two features. First, you must configure the 
switch to send syslog messages to the MARS Appliance. Next, you must configure the SNMP RO 
community for MARS to access available L2 information. 


To prepare the Extreme Ware device to generate the data required by MARS, follow these steps: 


For syslog configuration, add this command: 


configure syslog add <MARS’s IP address> local7 debug 
enable syslog 


For SNMP configuration add these commands: 


enable snmp dot1ldTpFdbTable 

configure snmp delete community readonly all 

configure snmp delete community readwrite all 

configure snmp add community readonly encrypted <encrypted community string> 
configure snmp add community readwrite encrypted <encrypted community string> 
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Add and Configure an ExtremeWare Switch in MARS 


Step 1 
Step 2 
Step 3 


Step 4 


Step 5 


Step 6 


Step7 


Step 8 


Step 9 


To add and configure an ExtremeWare switch in MARS, follow these steps: 


Select Admin > System Setup > Security and Monitor Devices > Add. 
Select Extreme ExtremeWare 6.x from the Device Type list. 
Enter the name of the device in the Device Name field. 


MARS maps this name to the reporting IP address. This name is used in topology maps, queries, and in 
the Security and Monitoring Device list. For devices that support the discovery operation, such as routers 
and firewalls, MARS renames this field’s value to match the name discovered in the device 
configuration, which typically uses the hostname.domain format. For devices that cannot be discovered, 
such as Windows and Linux hosts and host applications, MARS uses the provided value. 


(Optional) To enable MARS to discover settings from this device, enter the administrative IP address in 
the Access IP field. 


To learn more about the access IP address, its role, and dependencies, see Understanding Access IP, 
Reporting IP, and Interface Settings, page 2-8. 


Enter the IP address of the interface that publishes syslog messages, SNMP notifications, or both in the 
Reporting IP field. 


To learn more about the reporting IP address, its role, and dependencies, see Understanding Access IP, 
Reporting IP, and Interface Settings, page 2-8. 

If you entered an address in the Access IP field, select SNMP from the Access Type list. 

For more information on understanding the access type, see Selecting the Access Type, page 2-10. 
(Optional) To enable MARS to retrieve MIB objects for this reporting device, enter the device’s 
read-only community string in the SNMP RO Community field. 


Before you can specify the SNMP RO string, you must define an access IP address. MARS uses the 
SNMP RO string to read MIBs related to a reporting device’s CPU usage, network usage, and device 
anomaly data and to discover device and network settings. 


To add this device to the MARS database, click Submit. 


Result: The submit operation records the changes in the database tables. However, it does not load the 
changes into working memory of the MARS Appliance. The activate operation loads submitted changes 
into working memory. 


Click Activate. 


Result: MARS begins to sessionize events generated by this device and evaluate those events using the 
defined inspection and drop rules. Any events published by the device to MARS before activation can 
be queried using the reporting IP address of the device as a match criterion. 


Generic Router Device 


You can add any L2 or L3 device to the MARS as long as SNMP is enabled on the device. A generic 
router refers to any L2 or L3 device that is not listed in the Supported Devices and Software Versions for 
CS-MARS Local Controller 4.1. 
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Add and Configure a Generic Router in MARS 


Step 1 
Step 2 
Step 3 


Step 4 


Step 5 


Step 6 


Step7 


Step 8 


Step 9 


To add and configure a generic router device in MARS, follow these steps: 


Select Admin > System Setup > Security and Monitor Devices > Add. 
Select Generic Router version unknown from the Device Type list. 
Enter the name of the device in the Device Name field. 


MARS maps this name to the reporting IP address. This name is used in topology maps, queries, and in 
the Security and Monitoring Device list. For devices that support the discovery operation, such as routers 
and firewalls, MARS renames this field’s value to match the name discovered in the device 
configuration, which typically uses the hostname.domain format. For devices that cannot be discovered, 
such as Windows and Linux hosts and host applications, MARS uses the provided value. 


(Optional) To enable MARS to discover settings from this device, enter the administrative IP address in 
the Access IP field. 


To learn more about the access IP address, its role, and dependencies, see Understanding Access IP, 
Reporting IP, and Interface Settings, page 2-8. 


Enter the IP address of the interface that publishes syslog messages, SNMP notifications, or both in the 
Reporting IP field. 


To learn more about the reporting IP address, its role, and dependencies, see Understanding Access IP, 
Reporting IP, and Interface Settings, page 2-8. 


If you entered an address in the Access IP field, select SNMP from the Access Type list. 
For more information on understanding the access type, see Selecting the Access Type, page 2-10. 


(Optional) To enable MARS to retrieve MIB objects for this reporting device, enter the device’s 
read-only community string in the SNMP RO Community field. 


Before you can specify the SNMP RO string, you must define an access IP address. MARS uses the 


SNMP RO string to read MIBs related to a reporting device’s CPU usage, network usage, and device 
anomaly data and to discover device and network settings. 


To add this device to the MARS database, click Submit. 


Result: The submit operation records the changes in the database tables. However, it does not load the 
changes into working memory of the MARS Appliance. The activate operation loads submitted changes 
into working memory. 


Click Activate. 


Result: MARS begins to sessionize events generated by this device and evaluate those events using the 
defined inspection and drop rules. Any events published by the device to MARS before activation can 
be queried using the reporting IP address of the device as a match criterion. 
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Configuring Firewall Devices 


This chapter describes how to bootstrap firewall devices and add them to MARS as reporting devices. 
Firewall devices come in several form factors: hardware appliances, software applications running on a 
host, modules that are installed in switches and routers, and modules that install in multifunction security 
devices. 


Multifunction security devices, such as the Cisco Adaptive Security Appliance (ASA), also support 
non-firewall modules, such as intrusion detection or prevention systems (IDS/IPS). This chapter does 
not focus on configuring non-firewalling modules. Such discussions are provided in Configuring 
Network-based IDS and IPS Devices, page 6-1. 


This chapter explains how to bootstrap and add the following firewall devices to MARS: 
e Cisco Firewall Devices (PIX, ASA, and FWSM), page 4-1 
e NetScreen ScreenOS Devices, page 4-11 
e Check Point Devices, page 4-19 


Cisco Firewall Devices (PIX, ASA, and FWSM) 


MARS support for Cisco firewall devices includes the following: 
e PIX Security Appliance, including PIX software releases 6.0, 6.1, 6.2, 6.3 and 7.0. 
e Cisco Adaptive Security Appliance (ASA) 7.0 
e Cisco Firewall Services Modules (FWSM), versions 1.1, 2.2, and 2.3. 


Because these PIX software is mostly backward compatible, the commands required to bootstrap PIX 
security appliance remain consistent across the releases. In addition, Cisco ASA and FWSM have much 
in common with PIX command set. 


The taskflow required to configure MARS to monitor a Cisco firewall device is as follows: 
1. Configure the Cisco firewall device to accept administrative sessions from MARS (to discover 
settings). 


For Cisco ASA, PIX 7.0, and FWSM device types, you configure the admin context to accept these 
sessions. 


® 
Note Tobe monitored by MARS, the Cisco ASA, PIX 7.0, and FWSM device types have the following 


two requirements: each context requires a unique routable IP address for sending syslog 
messages to MARS, and each context must have a unique name (hostname+ domain name). 


| 78-17020-01 


User Guide for Cisco Security MARS Local Controller | 


Chapter4 Configuring Firewall Devices | 


HI Cisco Firewall Devices (PIX, ASA, and FWSM) 


2. Configure the Cisco firewall device to publish its syslog events to MARS. 


For Cisco ASA, PIX 7.0, and FWSM device types, you must configure the admin context and each 
security context. 


S 
Note MARS uses syslog events to discover information about the network topology. It uses SNMP to 
discover CPU utilization and related information. 


3. Within MARS, define the Cisco firewall device by providing the administrative connection 
information. 


S 
Note Before you can add an FWSM module in a switch, you must add and configure the base module 
(the Cisco switch) in MARS. For more information, Cisco Switch Devices, page 3-9. 


For Cisco ASA, PIX 7.0, and FWSM, the basic device type represents the admin context. However 
you must also define or discover each security context and any installed Advanced Inspection and 
Prevention (AIP) modules running IPS 5.0. 
To configure MARS to accept syslog event data and to pull device configurations settings from a Cisco 
firewall device, you must perform the following tasks: 


e Bootstrap the Cisco Firewall Device, page 4-2 
e Add and Configure a Cisco Firewall Device in MARS, page 4-5 


Bootstrap the Cisco Firewall Device 


You should configure your Cisco firewall devices to act as reporting devices and manual mitigation 
devices because they perform multiple roles on your network. MARS can benefit from the proper 
configuration of specific features: 
e IDS/IPS signature detection. While it does not boast the most efficient or comprehensive set of 
signatures, the built-in IDS and IPS signature matching features of the Cisco firewall device can be 
critical in detecting an attempted attack. 


e Accept/Deny Logs. The logging of accepted as well as denied sessions aids in false positive 
analysis. 
e Administrative Access. Administrative access ensure MARS access to several key pieces of data: 
- Route and ARP tables, which aid in network discovery and MAC address mapping. 
- NAT and PAT translation tables, which aid in address resolution and attack path analysis, 
exposing the real instigator of attacks. 
- OS Settings, from which MARS determines the correct ACLs to block detected attacks, which 


paste into a management session with the Cisco firewall device. 


To bootstrap the Cisco firewall device, you must identify the MARS Appliance as an administrative host 
Enabling administrative access allows MARS to discover the Cisco firewall device configuration 
settings. To enable administrative access, you must make sure that the MARS Appliance is granted 
Telnet or SSH administrative access to the firewall device. If you use FTP access type, make sure that 
you have added its configuration file to an FTP server to allow MARS access to the FTP server. 
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In addition to configuring specific event types and administrative access, syslog messages should be sent 
to the MARS Appliance. To prepare the Cisco firewall device to send these messages to the MARS 
Appliance, you must configure the logging settings associated with each firewall device on your 
network. To prepare a firewall device to generate the syslog messages and direct them to a specific 
MARS Appliance, you must: 


1. Enable logging on the firewall device. 


Before a firewall device can generate syslog messages, you must enable logging for one or more 
interfaces. In addition, if you configured your firewall device in a failover pair, you can specify the 
standby firewall device to generate syslog messages as well. You can enable the device to ensure 
that the standby unit's syslog messages stay synchronized if failover occurs. However, this option 
results in twice as much traffic on the MARS Appliance. 


2. Select the log facility and queue size. 


To generate meaningful reports about the network activity of a firewall device and to monitor the 
security events associated with that device, you must select the appropriate logging level. The 
logging level generates the syslog details required to track session-specific data. After you select a 
logging level, you can define a syslog rule that directs traffic to the MARS Appliance. 


3. Select the log level to debug. 


This setting generates syslog messages that assist you in debugging. it also generates logs that 
identify the commands issued during FTP sessions and the URLs requested during HTTP sessions. 
It includes all emergency, alert, critical, error, warning, notification, and information messages. 


wy 


Note Full URLs, such as www.cisco.com/foo.html, are included in HTTP session logs and FTP 
command data is logged only if web filtering (N2H2\SecureComputing or WebSense) is 
enabled on the reporting device. If web filtering is not enabled, then the HTTP session log 
does not include the hostname (although the destination host's IP and the Request-URI are 
included, such as 192.168.1.1:/f00.htm) and FTP command data is not logged at all. 
Caveats exist with HTTP session logging, such as if the HTTP session request is broken 
across packets, then the hostname data might not be included in the log data. 


4. Identify the target MARS Appliance and the protocol and port pair that it listens on. 


By directing syslog messages generated by a firewall device to MARS, you can process and study 
the messages. 


Tip 


When monitoring a failover pair of Cisco firewall devices, you should designate the primary Cisco 
firewall device as the device to be monitored. If failover occurs, the secondary device assumes the IP 
address of the primary, which ensures that session correlation is maintained after the failover. The same 
focus on the primary is true for performing any bootstrap operations. The secondary device will 
synchronize with the configuration settings of the primary. 


To enable administrative connections to the firewall device, select from the following options: 
e Enable Telnet Access on a Cisco Firewall Device, page 4-4 
e Enable SSH Access on a Cisco Firewall Device, page 4-4 
e Send Syslog Files From Cisco Firewall Device to MARS, page 4-4 
To configure log settings, see Send Syslog Files From Cisco Firewall Device to MARS, page 4-4. 
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Enable Telnet Access on a Cisco Firewall Device 


Step 1 Log in to the Cisco firewall device with administrator’s privileges. 
Step2 Enter the command: 


telnet <MARS IP address> <netmask of MARS IP address> <interface name> 


where interface name can be inside, outside, DMZ. 


Enable SSH Access on a Cisco Firewall Device 


Step 1 Log in to the Cisco firewall device with administrator’s privileges. 
Step2 Enter the command: 


ssh <MARS IP address> <netmask of the MARS IP address> <interface name> 


where interface name can be inside, outside, DMZ. 


Send Syslog Files From Cisco Firewall Device to MARS 


When preparing a Cisco firewall device to publish syslog messages, consider the following restrictions: 


¢ Do not customize the priority of any syslog messages. If you do, MARS fails to parse those 
messages. 


¢ Do not configure EMBLEM format for syslog messages. Make sure neither of the following 
commands are used in the configuration: 


logging host <interface name> <PN-MARS’s IP address> format EMBLEM 
logging emblem 


To send syslog messages to the MARS Appliance, you must enable logging, select the log facility and 
queue size, and specify the log level to debug. 


Step 1 Log in to the Cisco firewall device with administrator’s privileges. 
Step2 To enable logging, enter one of the following commands: 
e (PIX and Cisco ASA) logging enable 
e (FWSM) logging on 
Step3 To specify the MARS Appliance as a target logging host, enter the following command: 
logging host <interface name> <MARS IP address> 
Step4 To set the log level to debug, which ensures that HTTP and FTP session logs are generated, enter the 
following command: 


logging trap debugging 
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Step 6 


Step7 
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The debug messages contain the HTTP URL address information. Therefore, you can create 
keyword-based rules matching against the firewall message itself. For example, if the debug messages 
are enabled and users were logging to “http://mail.cisco.com”, you could create keyword-based rules 
that matched against “mail.yahoo.com.” 


S 


Note Full URLs, such as www.cisco.com/foo.html, are included in HTTP session logs and FTP 
command data is logged only if web filtering (N2H2\SecureComputing or WebSense) is enabled 
on the reporting device. If web filtering is not enabled, then the HTTP session log does not 
include the hostname (although the destination host's IP and the Request-URI are included, such 
as 192.168.1.1:/f00.htm) and FTP command data is not logged at all. Caveats exist with HTTP 
session logging, such as if the HTTP session request is broken across packets, then the hostname 
data might not be included in the log data. 


Debug messages are also preferred for troubleshooting. You can define inspection rules that match on 
on debug-level keywords, which send notifications to the appropriate group. Refer to PIX debug 
messages for interesting keywords. 


Cisco recommends enabling debug for optimal use of your STM solution. If a Cisco firewall device is 

unable to sustain debug-level messages due to performance reasons, the informational level should be 

used. In non-debug mode, the URL information is not available; only the 5 tuple is available for queries 
and reports. 


For FWSM, enter the following command: 

logging rate-limit <eps rate desired> 1 

For Cisco ASA, PIX 7.0, and FWSM, repeat Step 2 through Step 5 for each context defined, admin and 
security. 


(Cisco ASA only) If an Advanced Inspection and Prevention (AIP) module is installed, you need to 
prepare that module as you would any IPS 5.0 module. For more information, see Cisco IPS Modules, 
page 6-9. 


Add and Configure a Cisco Firewall Device in MARS 


The process of adding a PIX security appliance, Cisco ASA, or FWSM to MARS involves many of the 
same steps, regardless of the version of software that is running. The process is exactly the same for PIX 
software versions 6.0, 6.1, 6.2, and 6.3. However, Cisco ASA, PIX 7.0, and FWSM provide the ability 
to define multiple security contexts, or virtual firewalls. 


Adding a Cisco ASA, PIX 7.0, and FWSM to MARS has two distinct steps. First, you must define the 
settings for the admin context. Then, if multiple context mode is enabled, you define or discover the 
settings for its security contexts. These Cisco firewall device have two type of contexts: one admin 
context, which is used for configuration of the device itself, and one or more security contexts. For 
Cisco ASA, you can also define or discover any modules that are installed in the appliance. 


To be monitored by MARS, the Cisco ASA, PIX 7.0, and FWSM device types have the following 
additional requirements: 


¢ each context requires a unique routable IP address for sending syslog messages to MARS 


e each context must have a unique name (hostname+ domain name) 
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Note 


Step 1 


Step 2 


Step 3 


The Cisco ASA, PIX 7.0, and FWSM can run in single context mode, which means that the system 
context acts as both the admin context and a security context. 


To add and configure a Cisco firewall device, follow these steps: 


Do one of the following: 


e If you are adding an FWSM, you must be on the main page of the Cisco switch to which you are 
adding it. On that page, click Add Module. 


e If you are adding a PIX security appliance or a Cisco ASA, an Select Admin > System Setup > 
Security and Monitor Devices > Add. 


Select one of the following options from the Device Type list. 

e Cisco PIX 6.0 

e Cisco PIX 6.1 

e Cisco PIX 6.2 

e Cisco PIX 6.3 

e¢ Cisco PIX 7.0 

e Cisco ASA 7.0 

e Cisco FWSM 1.1 

e Cisco FWSM 2.2 

¢ Cisco FWSM 2.3 


Device Type: | Cisco PIX 7.0 “i 

> *Device Name: Admin 
> *Access IP: 10) }41 41 2 
> *Reporting IP: 100 Wt 41 2 
> *Access Type: SSH v 3DES “i 

Login: pix 

Password: 

Enable Password: eovccees 

Config Path: 

File Name: 

SNMP RO Community: public 


143178 


Discover Next 


Enter the name of the firewall device in the Device Name field. 


MARS maps this name to the reporting IP address. This name is used in topology maps, queries, and in 
the Security and Monitoring Device list. For devices that support the discovery operation, such as routers 
and firewalls, MARS renames this field’s value to match the name discovered in the device 
configuration, which typically uses the hostname.domain format. For devices that cannot be discovered, 
such as Windows and Linux hosts and host applications, MARS uses the provided value. 
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(Optional) To enable MARS to discover settings from this firewall device, enter the administrative IP 
address in the Access IP field. 


Step 5 


s 


If the device is running Cisco ASA, PIX 7.0, or FWSM, this address corresponds to IP address from 
which the syslog messages of the admin context are sent. 


To learn more about the access IP address, its role, and dependencies, see Understanding Access IP, 
Reporting IP, and Interface Settings, page 2-8. 


Enter the IP address of the interface that publishes syslog messages or SNMP notifications, or both in 
the Reporting IP field. 


Note 


Step 6 


If the device is running Cisco ASA, PIX 7.0, or FWSM, this address corresponds to the address from 
which the admin context syslog messages are published. 


To learn more about the reporting IP address, its role, and dependencies, see Understanding Access IP, 
Reporting IP, and Interface Settings, page 2-8. 


If you entered an address in the Access IP field, select TELNET, SSH, or FTP from the Access Type 
list, and continue with the procedure that matches your selection: 


e Configure Telnet Access for Devices in MARS, page 2-11 
e Configure SSH Access for Devices in MARS, page 2-12 
e Configure FTP Access for Devices in MARS, page 2-12 


Step7 


Step 8 


Step 9 


If you select the FTP access type and you are defining a Cisco ASA, PIX 7.0, or FWSM, you cannot 
discover the non-admin context settings. Therefore, this access type is not recommended. 


For more information on determining the access type, see Selecting the Access Type, page 2-10. 


(Optional) To enable MARS to retrieve MIB objects for this reporting device, enter the device’s 
read-only community string in the SNMP RO Community field. 


Before you can specify the SNMP RO string, you must define an access IP address. MARS uses the 
SNMP RO string to read MIBs related to a reporting device’s CPU usage, network usage, and device 
anomaly data and to discover device and network settings. 


(Optional) To enable MARS to monitor this device for anomalous resource usage, select Yes from the 
Monitor Resource Usage list. 


Result: MARS monitors the device for anomalous consumption of resources, such as memory and CPU. 
If anomalies are detected, MARS generates an incident. Resource utilization statistics are also used to 
generate reports. For more information, see Configuring Resource Usage Data, page 2-41. 


(Cisco ASA, FWSM, and PIX 7.0 Only) do one of the following: 


e Click Discover to let MARS contact the device and conduct a topology and context configuration 
discovery. Information about the security contexts is presented in the Context section of the main 
page. To edit discovered contexts, continue with Edit Discovered Security Contexts, page 4-11. 


e Click Next to commit your changes and allow for manual definition of security contexts or modules. 
Continue with Add Security Contexts Manually, page 4-8, Add Discovered Contexts, page 4-10, or 
Add an IPS Module to a Cisco Switch or Cisco ASA, page 6-11. 
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For PIX and FWSM, you can add one or more security contexts. For Cisco ASA, you can add one 
or more security contexts or Advanced Inspection and Prevention (AIP) modules, running the Cisco 
IPS 5.x software. 


Device Type: Cisco PIX 7,0 
> *Device Name: Admin 
> *Access IP: 10 fi I! 1 {2 
> *Reporting IP: 10 fi 41 2 
> *Access Type: SSH vv 3DES v 
Login: pix 
Password: eecccece 
Enable Password: ecocccce 
Config Path: 
File Name: 
SNMP RO Community: public 
Add Context | Edit Context I Remove Context Add Available Context 
nN 
oO 
< Back Discover Submit o 


Step10 (Optional) If you defined an access IP and selected and configured an access type, click Discover to 
determine the device settings, including any security contexts and their settings. 


Result: If the username and password are correct and the MARS Appliance is configured as an 
administrative host for the device, the “Discovery is done.” dialog box appears when the discovery 
operation completes. Otherwise, an error message appears. After the initial pull, the MARS Appliance 
pulls based on the schedule that you define. For more information, see Scheduling Topology Updates, 
page 2-39. 


Step 11 To add this device to the MARS database, click Submit. 


Result: The submit operation records the changes in the database tables. However, it does not load the 
changes into working memory of the MARS Appliance. The activate operation loads submitted changes 
into working memory. 


Step12 Click Activate. 


Result: MARS begins to sessionize events generated by this device and evaluate those events using the 
defined inspection and drop rules. Any events published by the device to MARS before activation can 
be queried using the reporting IP address of the device as a match criterion. For more information on the 
activate action, see Activate the Reporting and Mitigation Devices, page 2-27. 


Add Security Contexts Manually 


You can manually define security contexts in PIX 7.0, Cisco ASA, or FWSM. 
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Step 2 


Step 3 


Step 4 


Step 5 


Step 6 


Step7 


Step 8 
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Do one of the following: 
e (PIX 7.0 and FWSM) Click Add Context. 
e (Cisco ASA) Click Add Module. 


Device Type: Cisco PIX 7.0 ¥ 


> *Device Name: 


> *Context Name: [context1 | 
SNMP RO Community: publid 


143179 


Cancel Submit 


In the Device Type list, do one of the following: 
e For Cisco ASA, select Cisco ASA 7.0. 
e For PIX 7.0, select Cisco PIX 7.0. 


e For FWSM, select Cisco FWSM x.y, where x.y is the version number of the software running on the 
module. 


Enter the name of the firewall device in the Device Name field. 


MARS maps this name to the reporting IP address. This name is used in topology maps, queries, and in 
the Security and Monitoring Device list. For devices that support the discovery operation, such as routers 
and firewalls, MARS renames this field’s value to match the name discovered in the device 
configuration, which typically uses the hostname.domain format. For devices that cannot be discovered, 
such as Windows and Linux hosts and host applications, MARS uses the provided value. 


Enter the name of the security context in the Context Name field. 
This name must exactly match the context name defined on the device. 


Enter the IP address of the security context from which syslog messages or SNMP notifications, or both 
are published in the Reporting IP field. 


To learn more about the reporting IP address, its role, and dependencies, see Understanding Access IP, 
Reporting IP, and Interface Settings, page 2-8. 


(Optional) To enable MARS to retrieve MIB objects for this security context, enter the device’s 
read-only community string in the SNMP RO Community field. 


Before you can specify the SNMP RO string, you must define an access IP address. MARS uses the 
SNMP RO string to read MIBs related to a security context’s CPU usage, network usage, and device 
anomaly data and to discover device and network settings. 


To discover the settings of the defined context click Discover. 


This discovery collects all of the route, NAT, and ACL-related information. In addition, the name of the 
device may change to the hostname.domain format if it was not already entered as such. 


To save your changes, click Submit. 
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Add Discovered Contexts 


When you select Discover on a Cisco ASA, PIX 7.0 or FWSM, MARS discovers the contexts that are 
defined for that firewall device. However, you must still manually add discovered contents. 


Note You cannot discover a module install in a Cisco ASA; you must manually define IPS modules. However, 
the discovered contexts do appear under the Module area on the main page. 


Step 1 Do one of the following: 
e (PIX 7.0 and FWSM) Click Add Available Context. 
e (Cisco ASA) Click Add Available Module. 


Add Module Edit Module Remove Module Add Available Module 


[ [Module Name [Module Type | 
J. asa context Cisco 4S4 7.0 
[~ ips context Cisco IPS 5.x fe 
* 
t 
Step2 Select a security context from the Select list. 
Select:| asa context2 |v 
t 
~~ 
: 


Step3 = Click Add. 
Step4 Repeat for other contexts. 
Step5 To save your changes, click Submit. 


After you add discovered contexts, you must edit them to provide the contact information required by 
MARS. Continue with Edit Discovered Security Contexts, page 4-11. 
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Edit Discovered Security Contexts 


\ 


Note 


Step 1 


Step 2 


Step 3 


Step 4 


Step 5 
Step 6 


You must edit all discovered contexts to specify the reporting IP address and the SNMP RO community 
string. 


From the list of discovered contexts, select the one that you want to edit and select the action appropriate 
to the device type: 


e (PIX 7.0) Click Edit Context. 
e (Cisco ASA and FWSM) Click Edit Module. 


Device Type: Cisco 434 7,0 
> *Device Name: qa.protegonetworks.col 
> *Context Name: lqa | 
=> *Reporting IP: fio la | je] 
SNMP RO Community: [public 
_| 
Discover Cancel Submit 5 
wT 


Enter the IP address from which the syslog messages of the security context are sent in the Reporting IP 
field. 


(Optional) To enable MARS to retrieve MIB objects for this context, enter the device’s read-only 
community string in the SNMP RO Community field. 


Before you can specify the SNMP RO string, you must define an access IP address. MARS uses the 
SNMP RO string to read MIBs related to a reporting device’s CPU usage, network usage, and device 
anomaly data and to discover device and network settings. 


(Optional) To enable MARS to monitor this context for anomalous resource usage, select Yes from the 
Monitor Resource Usage list. 


Result: MARS monitors the device for anomalous consumption of resources, such as memory and CPU. 
If anomalies are detected, MARS generates an incident. Resource utilization statistics are also used to 
generate reports. For more information, see Configuring Resource Usage Data, page 2-41. 


To save your changes, click Submit. 


Repeat for each discovered context. 


NetScreen ScreenOS Devices 


MARS can monitor NetScreen ScreenOS devices, versions 4.0 and 5.0. To enable this monitoring, you 
must: 


1. Provide MARS with SNMP, SSH or Telnet administrative access to NetScreen device. 
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2. Define the SNMP RO community strings to shared between the NetScreen device and MARS. 
3. Specify which syslog messages to published to MARS. 
4. Add the Netscreen Device to the MARS web interface. 
To accomplish these requirements, you must perform two procedures: 
e Bootstrap the NetScreen Device, page 4-12 
e Add the NetScreen Device to MARS, page 4-17 


Bootstrap the NetScreen Device 


To prepare the NetScreen device to be monitored by MARS, follow these steps: 


Step1 _ Login to the NetScreen with appropriate username and password. 


Step2 In the main screen, on the left hand column click Network > Interfaces. 


Network > Interfaces (List) NS5GT-DI 2 | 


List |20 ¥|per page 


List [ALL(A) interfaces New | [Tunnel IF 7] 


Name | IP/Netmask | Zo Type “Link | PPPoE Ee amare 
serial 0.0.0.0/0 Untrust | Layer3 |down| — - 
trust | 192.168.5.200/24| Trust | Layer3 | up | 

untrust | 171.69,230.44/26 | untrust [Layers [ up - 


vlanl | 0.0.0.0/0 | VLAN | Layers | down | 7 


: 


a 
+ 
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Step3 Click Edit next to the appropriate interface to configure for MARS to have access to SNMP and 
Telnet/SSH. 
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Network > Interfaces > Edit NS5GT-DI 
Interface: trust (IP/Netmask: 192.168.5.200/24) Back To Interface 


2 
Juniper Properties: Basic MIP DIP SecondaryIP IGMP 
Bren. SECURE Interface Name trust (mac 0010.dbSb.8dd2) 


NetScreen-5GT Zone Name [Trust | 


© Obtain IP using DHCP J Automatic update DHCP server parameters 


Other Services V Ping I” Ident-reset 


Maximum Transfer Unit 
1500 Bytes 
(MTU) 


e 
on 
a © Obtain IP using PPPoE [None | © Create new pppoe setting 
1 
| i © static IP 
+ 
| . : IP Address / Netmask [192.168.5.200 / fea M Manageable 
| is Manage IP * |fEEREER ein (mac 0010.db5b.8dd2) 
K —————— EE eee ee 
| 
| Interface Mode @ NAT © Route 
| Block Intra-Subnet Traffic [~ 
} Service Options 
FE pies Rael Sip renee AN ¥ Telnet 1 SSH 
9 ¥ SNMP ¥ SsL 
a 
is 


DNS Proxy [~ 


Webauth [Ip [0.0.0.0 IT SSL Only 
Traffic Bandwidth fo Kbps 
—oK | _Apply_| cancel | 
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Step4 | Under Service Options, select one of the following values: 
¢ SNMP 
e Telnet 
e SCS (4.0 only) 
e SSH (5.0 and later) 


MARS can only use one of the access methods to perform configuration discovery. This value will also 
be selected in the Access Type value of Add the NetScreen Device to MARS, page 4-17. 


Step5 Click Apply then click OK. 
Step6 Configure the SNMP information by selecting Configure > Report Settings > SNMP. 
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Step 7 
Step 8 


Step 9 


NetScreen -5GT 


4 
| 
| 
| 
| 


[+P 


a+ + 


Configuration > Report Settings > SNMP NSS5GT-DI ? | 


New Community | 


SNMP Report Settings 
System Name [NSSGT-DI 


System Contact eee 
Location [rr 
Listen Port fier 
Trap Port [162 


Enable Authentication Fail vw 
v 
Trap 


Apply | Cancel | 


Name Trap Traffi ic | Hosts Configure 
No entry TET: 


Communities: 
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Add the MARS IP address in the Host List by clicking Edit. 


Enter the MARS IP address and verify that this Community Name in this window is the same community 


string entered in the MARS web interface when adding this device. 


(Optional) If the community string does not match, click New Community to define one that matches 


the on defined in MARS. 
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Configuration > Report Settings > SNMP > Community Edit NS5GT-DIFQ 


NetScreen -5GT 


O-o- 


Hosts IP Address Netmask Trap Yersion | Source Interface 


+ Fl + | 


L+ P+ a+ | 
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Step 10 Configure the Syslog information by selecting Configure > Report Settings > Syslog. 
Step11. Verify that the Enable Syslog Messages and Include Traffic Log boxes are checked. 
Step12 Enter the IP address of the MARS Appliance that will listen for events from this device 
Step 13 Verify that the default syslog port number of 514 is selected. 

Step14 Select the AUTH/SEC for Security Facility and LOCALO for Facility. 

Step15 For NetScreen 5.0, select the Event Log in addition to Traffic Log. 

Step16 Click Apply. 
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Configuration > Report Settings > Syslog NS5GT-DI @ 


Apply Apply and Reset connections 
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Step17 Configure logging for each policy that user wants to send the events to the MARS Appliance. Select 
Policies on the left hand area. 


Policies (From All zones To All zones) NSS5SGT-DI |? | 


A 5 List |20 *¥Jper page Search | 
eb Juniper From all zones >| To ail zones >| Go | New 
WENO secure 


NetScreen-5GT From Untrust To Trust, total policy: 1 


ID Source Destination Service Action Options __———Gonfigure__—_Enable_ Move 
@ AZ’ |edit | clone Remove) 


From Trust To Untrust, total policy: 3 


| Service (Action Options ___—_—Gonfigure___ Enable 
1 | Any Any ANY @ Edit |Clone|Remove| 


DNS 
GNUTELLA 
HTTP 


HTTP 
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Step18 Click Edit then Advance and verify that Logging box is checked. Repeat for all policies which events 
need to be sent to MARS. 


User Guide for Cisco Security MARS Local Controller 
P46 78-17020-01 | 


| Chapter 4 


Configuring Firewall Devices 


Step 19 


NetScreen ScreenOS Devices Mil 


Policies (From Untrust To Trust) NS5GT-DI |? | 


NetScreen -5GT Name (optional) j 


© New Address j | 
@ Address Book Entry [Any >| Multiple | 


- New Address EE 
Destination Address : 
@ Address Book Entry JAny x] Multiple | 


Service [HTTP S| Multiple | 
Application [None >| 


-o-— 
el! 


Source Address 


a 
| 
I 
te 
| 

o 


[URL Filtering 


Action [Permit x] Deep Inspection | 
<< | Available AY Object Names 
scan-mar 
>> | 


Attached AV Object Names 


Antivirus Objects 


Tunnel vpn [None | 


I Modify matching bidirectional VPN policy 


L2TP [None | 


Logging Vv 


OK | Cancel | Advanced | 
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Verify that all the Syslog event severity levels that need to be sent to MARS are configured. Verify which 
Syslog severity levels that are enabled by selecting Configuration > Report Settings > Log Settings. 


Add the NetScreen Device to MARS 


Step 1 
Step 2 
Step 3 


Step 4 


Select Admin > System Setup > Security and Monitor Devices > Add. 
Select the appropriate version of NetScreen ScreenOS from the Device Type list. 
Enter the name of the device in the Device Name field. 


MARS maps this name to the reporting IP address. This name is used in topology maps, queries, and in 
the Security and Monitoring Device list. For devices that support the discovery operation, such as routers 
and firewalls, MARS renames this field’s value to match the name discovered in the device 
configuration, which typically uses the hostname.domain format. For devices that cannot be discovered, 
such as Windows and Linux hosts and host applications, MARS uses the provided value. 


(Optional) To enable MARS to discover settings from this device, enter the administrative IP address in 
the Access IP field. 


To learn more about the access IP address, its role, and dependencies, see Understanding Access IP, 
Reporting IP, and Interface Settings, page 2-8. 
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Step 5 


Step 6 


Step7 


Step 8 


Step 9 


Step 10 


Enter the IP address of the interface that publishes syslog messages or SNMP notifications, or both in 
the Reporting IP field. 


To learn more about the reporting IP address, its role, and dependencies, see Understanding Access IP, 
Reporting IP, and Interface Settings, page 2-8. 


If you entered an address in the Access IP field, select SNMP, TELNET, or SSH, from the Access Type 
list, and continue with the procedure that matches your selection: 


e Configure SNMP Access for Devices in MARS, page 2-11 
e Configure Telnet Access for Devices in MARS, page 2-11 
e Configure SSH Access for Devices in MARS, page 2-12 
For more information on determining the access type, see Selecting the Access Type, page 2-10. 


(Optional) To enable MARS to retrieve MIB objects for this reporting device, enter the device’s 
read-only community string in the SNMP RO Community field. 


Before you can specify the SNMP RO string, you must define an access IP address. MARS uses the 
SNMP RO string to read MIBs related to a reporting device’s CPU usage, network usage, and device 
anomaly data and to discover device and network settings. 


(Optional) If you defined an access IP and selected and configured an access type, click Discover to 
determine the device settings. 


Result: If the username and password are correct and the MARS Appliance is configured as an 
administrative host for the device, the “Discovery is done.” dialog box appears when the discovery 
operation completes. Otherwise, an error message appears. After the initial pull, the MARS Appliance 
pulls based on the schedule that you define. For more information, see Scheduling Topology Updates, 
page 2-39, 


To add this device to the MARS database, click Submit. 


Result: The submit operation records the changes in the database tables. However, it does not load the 
changes into working memory of the MARS Appliance. The activate operation loads submitted changes 
into working memory. 


Click Activate. 


Result: MARS begins to sessionize events generated by this device and evaluate those events using the 
defined inspection and drop rules. Any events published by the device to MARS before activation can 
be queried using the reporting IP address of the device as a match criterion. For more information on the 
activate action, see Activate the Reporting and Mitigation Devices, page 2-27. 
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Check Point Devices 


The Check Point security product family can be distributed and tiered. As such, you must understand the 
deployment method, components, and release versions of this product family, their relationships, and 
how MARS interacts with them. You must also understand the many acronyms and abbreviations 
associated with this product family. Table 4-1 lists the abbreviations and acronyms used in the topics that 


follow. 

Table 4-1 Check Point Abbreviations and Acronyms 

Abbreviation Expansion Additional Information 

ASYMSSLCA_ |Secure Sockets Layer Certificate Communications protocol used for 

Authority using an asymmetric key cipher |establishing secure sessions. 

CLM Customer Log Modules Standalone log server for collecting log 
data from the Check Point enforcement 
modules. 

CMA Customer Management Add-ons A a virtual instance of SmartCenter and 
only exists within the context of a 
Provide-1/SiteManager-1 infrastructure. 

CPMI Check Point Management Interface Communications protocol used for 
configuration discovery. 

LEA Log Export API Communications protocol used for 
retrieving audit and firewall logs. 

MDG Multi Domain GUI GUI used for managing Provider-1/ 
SiteManager-1 deployments. The MDG is 
the parent GUI that can launch specific 
SmartDashboard GUIs for a CMA. 

MDS Multi Domain Server Is the umbrella manager for the CMA 
instances in a Provider-1/SiteManager- | 
deployment. 

MLM Multi Domain Log Module Usually found in Provider-1/ 
SiteManager-1 deployments and provides 
the ability to create multiple instances of 
a CLM on a single logging server. 

NG AI Next Generation with Application All current trains of Check Point are 

Intelligence released under the NG AI umbrella with 
specific release numbers, such as NG AI 
R55 and NG AI ROO. 

NG FP3 Next Generation Feature Pack 3 —_ 

NGX Next Generation eXtension NGxX is also NG AI R60 

OPSEC Open Platform for Security An alliance, certification and integration 
methodology for products and solutions 
that integrate into a Check Point 
infrastructure. 

P-1 Check Point Provider-1 — 
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Table 4-1 Check Point Abbreviations and Acronyms 
Abbreviation Expansion Additional Information 
SSLCA Secure Sockets Layer Certificate — 
Authority, using a symmetric key cipher 
(protocol) 
SIC Secure Internal Communication — 
SIC DN SIC Distinguished Name — 
VIPs Virtual IP Addresses Usually used in a Provider-1/ 


SiteManager-1 deployment to assign 
unique IP addresses for CMA instances. 


VPN-1 Check Point VPN-1 Pro and Edge VPN-1 Pro is the Check Point 
enforcement gateway that does the 
inspection, firewalling, VPN encryption 
and QoS tagging. 


VPN-1 Edge is treated as a normal 
enforcement point. 


To understand what MARS supports, we must first clarify the product terminology used by Check Point. 
NG refers to the 5.x product family, and it included three feature packs: FP1, FP2, and FP3. NG is 
different from NG AI in that NG AI improved upon, and renamed, the SmartDefense feature set that was 
introduced in NG FP2. NG AI also provides a larger number of application-aware inspections,; hence 
the name Application Intelligence. NG AI included releases R54 and R55. NGX refers to the 6.x product 
family and began with the R60 release. 


MARS supports and has been tested with the following releases: 


° NG FP3 
° NG AI (R55) 
° NGX (R60) 


The different security platforms, Provider-1, SiteManager-1, SmartCenter, and SmartCenter Pro are 
bundles of the technologies released under the NG, NG AI, and NGX release trains. From this 
perspective, MARS works with any of the security platforms as long as it belongs to one of the supported 
release trains. 


Check Point Provider-1 is a security management system for the managed security service providers 
(MSSP) and multi-site enterprises, respectively. Service providers are able to manage the Check Point 
gateways (firewall and VPN gateways) on their customer sites. The security policies and the system 
configurations are stored on the MDS. Each per-customer security policy is managed through a CMA, 
which also reside on the MDS. The Provider-1 system allows the service provider and the end customers 
to maintains separate log servers, using the MLM and CLM respectively. The user interface for 
Provider-1 is called the MDG. This system also support a tiered fault-tolerant configuration via 
redundancy at the gateway, CMA, or MDS level. 


The Provider-1 system ensures secure and private communication between its components and Check 
Point gateways. Each CMA has its own internal certificate authority that issues certificates for secure 
communication between the CMA, log servers, and its own network. All communication between MDSs 
is authenticated and secured, and every MDS communicates securely with the CMAs that it houses. 


The SiteManager-1 system operates much the same as Provider-1; however, it is targeted toward large 
enterprise customers. The Check Point components are the same as those found in Provider-1. 
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SmartCenter and SmartCenter Pro are security management systems also targeted toward enterprise 
customers. They can support the Provider-1 system, serving as a backup server at the CMA level. 
However, their primary function is to provide centralized security and VPN policy and security event 
management through SmartDashboard, which is the user interface for both systems. From the MARS 
perspective, SmartCenter has the ability to extend the view of the network by managing the policies and 
events associated with gateway and desktop nodes: 


e VPN-1 perimeter security gateways, 

e InterSpect internal security gateways 

e Connectra Web security gateways 

e SecureClient, a personal firewall running on desktops and servers. 


MARS monitors the primary management servers, such as the MDS in Provider-1 and SiteManager- 1 
and the SmartCenter Server in SmartCenter and SmartCenter Pro. These management servers are where 
the actual security and audit policies are centrally managed and stored. If the Check Point deployment 
requires, MARS also monitors those components managed by the management stations, such as 
individual firewalls, VPN gateways, and log servers. Whether you configure MARS to monitor these 
remote components depends on whether their security event logs are propagated to the centralized 
management servers (SmartCenter or CMA). If the logs are not forwarded to the primary management 
server, then you must define where the log repository exists, whether local to the enforcement module, 
or forwarded to a separate logging module (CLM). 


In addition to understanding the components, it is important to understand how Check Point components 
use Secure Internal Communications (SIC) to securely communicate with each other and with 
third-party OPSEC applications. SIC is the process by which MARS Appliance authenticates to the 
SmartCenter Server and other Check Point components. SIC uses a shared secret as the seed for 
negotiating session keys. This shared secret is referred to as an activation key. The authentication and 
communication setup works as follows: 


1. Using a username and password pair, MARS authenticates to the SmartCenter Server and other 
Check Point components, such as remote log servers, using TCP port 18210. 


2. If authenticated, the peers swap the activation key and each other’s SIC using TCP port 18190. 


3. If each peer validates the authenticity of the other, the Check Point component establish an 
encrypted session over TCP port 18184 with the MARS Appliance. It is over this channel that the 
Check Point components to sends encrypted log data to MARS. 


The following topics support the integration of MARS into a Check Point environment: 
e Determine Devices to Monitor and Restrictions, page 4-21 
e Bootstrap the Check Point Devices, page 4-22 
e Add and Configure Check Point Devices in MARS, page 4-36 
e Troubleshooting MARS and Check Point, page 4-53 


Determine Devices to Monitor and Restrictions 


To configure Check Point devices, you must identify the central management server and managed 
components, bootstrap them, and add and configure them in the MARS web interface. The Check Point 
product line and release, as well as the number of devices managed, determines which tasks you must 
perform to configure MARS to monitor your Check Point devices. 
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Representing a Check Point device in MARS involve two steps: 


1. Define a primary management station. This primary management station represents the central 
management server that manages remote components, such as firewalls, VPN gateways, and log 
servers. 


2. Define one or more child enforcement modules. Child enforcement modules are the remote 
components managed by the primary management station. They represent firewalls, VPN gateways, 
and log servers. 


When managing SmartCenter and SmartCenter Pro, the primary management station is the SmartCenter 
server. When managing Provider-1/SiteManager-1 releases NG FP3, NG AI (R55), and NGX (R60), the 
primary management station is not the MDS, but each CMA defined under the MDS. In other words, you 
must define each CMA as a separate primary management station. The child enforcement modules are 
those gateways and logs servers (CLMs) managed as part of that customer or site as defined by the CMA. 


Part of what you must determine is where the security event logs are stored. Two options exist: 


e Central Event Correlation. The MLM or SmartCenter server pulls logs from all remote 
components. 


e Distributed Event Correlation. In addition to the MLM or SmartCenter Server, one or more remote 
log servers exist where aggregation to the central management server does not occur. These severs, 
the CLMs, must also be represented and configure so that MARS can pull the events from them. 


If the security events are stored in a distributed fashion, you must plan to define and establish SIC 
communication between the MARS Appliance and each Check Point log module. For SmartCenter and 
SmartCenter Pro, the server SIC DN is the one assigned to the primary management station. However, 
for Provider-1 and SiteManager-1, the server SIC DN varies based on release. For Provider-1 and 
SiteManager-1 NG FP3 and NG AI (R55), the server SIC DN is the one associated with the CMA. For 
Provider-1! and SiteManager- 1 NGX (R60), you can use the SIC assigned to the MDS for all CMAs and 
CLMs that you define. 


One other restriction exists with the Provider-1 and SiteManager-1 products. For Provider-1 and 
SiteManager-1 NG FP3 and NG AI (R55), you must define an OPSEC application representing the 
MARS Appliance in each CMA (using the CMAs SmartDashboard user interface). For Provider-1 and 
SiteManager-1 NGX (R60), you can define one OPSEC application representing the MARS Appliance 
and push that definition to all CMAs and CLMs managed by the MDS. 


Bootstrap the Check Point Devices 


Bootstrapping the Check Point devices involves preparing those devices to send data to the MARS 
Appliance, as well as enabling the MARS Appliance to discover the Check Point configuration settings. 
In addition to preparing the Check Point devices, you must gather the information required to represent 
the Check Point devices in the MARS web interface. 


You bootstrap the central Check Point management server, whether it be a CMA or a SmartCenter server 
by defining the MARS Appliance as a target log host and OPSEC Application object. 


1. Using Check Point SmartDashboard or the Check Point Provider-1/SiteManager-1 MDG, add the 
MARS Appliance as a host. 


2. Create and install an OPSEC Application object for the defined host, import the authorization key, 
and generate the client SIC DN. This SIC DN is the one used by OPSEC applications, including the 
management server, to validate the MARS Appliance. You specify this client SIC DN in the MARS 
web interface. When a session is established between the MARS Appliance and the Check Point 
management server, the appliance publishes this SIC to the management server to ensure 
non-repudiation of the appliance. 
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Obtain the server SIC DN of the Check Point management server. You specify this sever SIC in the 
MARS web interface. The MARS Appliance validates the server SIC DN against the SIC published 
to the appliance by the management server during session setup. This validation ensures 
non-repudiation of the server. 


Create the policies to permit SIC traffic between the defined host (MARS Appliance), the Check 
Point management server, and any remote servers. After you identify the devices, you must verify 
that the network services they use for SIC-based management and reporting are permitted on the 
reporting device. To enable these traffic flows, you must verify or update the policies that enable the 
SIC traffic to flow between each reporting device and the MARS Appliance. Once you have updated 
these policies, you must install the policies. 


Define the log settings to push the correct events to the defined host. You must ensure that all of the 
security, firewall, user authentication, and audit events are logged and configured to be published to 
the MARS Appliance. 


Install the policies. Once the policies are defined, you must update the Check Point components with 
the policies. Policy installation include an object database push that make the Check Point modules 
aware of the OPSEC Application representing the MARS Appliance. Without this step, the modules 
will not forward any log information via LEA. 


To perform this task, you need a Check Point user account with administrative privileges. This account 
must be able to create a new host, define OPSEC application, define and install new policies, and access 
the settings of each managed Check Point component. 


After completing this task, you should have collected the following information: 


The Client and server SIC DNs. 


If you are defining a CMA for Provider-1 or SiteManager-1 NG FP3 or NG AI (R55), then you must 
have the virtual IP address (VIP) for each CMA and CLM managed by the MDS. Only Provider-1 
and SiteManager- 1 NGX (R60) requires the physical IP addresses of the MDS and MLM servers. 


Any CLMs, instead of CMAs, to which security logs are being sent. If logs are being sent to CLMs, 
LEA is only supported using clear text. 


To bootstrap the Check Point devices, perform the following procedures: 


Add the MARS Appliance as a Host in Check Point, page 4-23 

Define an OPSEC Application that Represents MARS, page 4-24 

Obtain the Server Entity SIC Name, page 4-27 

Select the Access Type for LEA and CPMI Traffic, page 4-29 

Create and Install Policies, page 4-31 

Verify Communication Path Between MARS Appliance and Check Point Devices, page 4-32 


Add the MARS Appliance as a Host in Check Point 


Representing the MARS Appliance in Check Point enables the following supporting tasks: 


Generate a client SIC DN for the MARS Appliance. 


Define policies to allow SIC and syslog traffic between the Check Point components and the MARS 
Appliance. 


Direct log traffic to the MARS Appliance. 


To define the MARS Appliance as a host, follow these steps: 
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Step 1 Log in to the correct Check Point user interface using an account with administrative privileges. 


If you are using SmartCenter, use the SmartDashboard for that server. If you are using Provider-1 or 
SiteManager-1 NG FP3 or NG AI (R55), use the SmartDashboard of the CMA. If you are using 
Provider-1 or SiteManager-1 NGX, use the MDG. 


Step2 Select Manage > Network Objects from the main menu. 
Result: The Network Objects dialog box appears. 
Step 3 Click the New button, and then select Node > Host on the menu list. 


Result: The Host Node dialog appears, with the General Properties settings selected. 


Host Node - testCsMars100 xi 


General Properties Host Node - General Properties 


Topology 


NAT Name: ftestCsM ars100 

Advanced 
IP Address: fi 92.168.3.100 Get address | 
Comment: 


Coo | | 
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Step4 Enter the name MARS Appliance in the Name field of the General Properties page 


Any Check Point policies defined to enable access or send logs to this appliance will reference the 
appliance by this name. Cisco best practice recommends using the actual hostname of the MARS 
Appliance. 


Step5 —_ Enter the IP address of the monitoring interface in the MARS Appliance in the IP Address field 


Typically, the monitoring interface is ethO. However, if one or more intermediate gateways are applying 
NAT rules to the physical IP address, enter the IP address that is exposed to the Check Point central 
management server. 


Step6 Click OK to close the Host Node dialog box. 
Step7 Click Close to close the Network Objects dialog box. 


Result: The host representing the MARS Appliance is defined. You can now use this host when defining 
new policies in the Check Point user interface. 


Step8 | Continue with Define an OPSEC Application that Represents MARS, page 4-24. 


Define an OPSEC Application that Represents MARS 


To integrate a third-party OPSEC application with Check Point components, you must define the 
application and associate it with the host on which the application is running. In addition to identifying 
this OPSEC application to the Check Point system, this procedure results in the generation of the client 
SIC DN for the MARS Appliance. Both the client SIC DN and the server SIC DN, obtained in Obtain 
the Server Entity SIC Name, page 4-27, are required to enable secure communications between the 
appliance and Check Point components. 


This procedure also involves selecting an activation key, or shared secret, that is also required to enable 
the secure communications. You must record both the activation key and the client SIC DN for use when 
defining the Check Point devices in the MARS web interface. 
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Step 3 


Step 4 


Step 5 


Step 6 


Step 7 
Step 8 
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Log in to the correct Check Point user interface using an account with administrative privileges. 


If you are using SmartCenter, use the SmartDashboard for that server. If you are using Provider-1 or 
SiteManager-1 NG FP3 or NG AI (R55), use the SmartDashboard of the CMA. If you are using 
Provider-1 or SiteManager-1 NGX, use the MDG. 


Select Manage > Servers and OPSEC Applications from the main menu. 
Result: The Servers and OPSEC Application dialog box appears. 

Click the New button, and then click OPSEC Application on the menu list. 
Result: The OPSEC Application Properties dialog box appears. 


OPSEC Application Properties - logCsMars100 xi 


General | CVP Options | CPMI Permissions | 


Name: flogCsMars100 

Comment: [oO 
Color: CL_FE 

Host: [Litestcsmarsioo | Ewe | 


Application properties 


Vendor: User defined 7] 
Product: j | Version: | | 


Server Entities Client Entities 
CvP 
UFP 
AMON 


Description: Log Export 4PI 
Secure Intermal Communication 


Communication... | DN: j 


Cancel | Help | 
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Specify the name for this object in the Name field. 


This value must be different from the name specified in Step 4 of Add the MARS Appliance as a Host 
in Check Point, page 4-23. Best practice recommends using the actual hostname of the host object plus 
some other descriptor, which combines for a unique name. 


In the Host list, select the host that you specified in Step 4 of Add the MARS Appliance as a Host in 
Check Point, page 4-23. 


Result: This OPSEC application definition is associated with the host that represents the MARS 
Appliance. 


Verify that User defined is selected in the Vendor field. 
Select the LEA and CPMI check boxes under Client Entities. 
These values identify the OPSEC services required by the MARS Appliance. 
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Step9 Click the Communication button under Secure Internal Communication. 


Result: The Communication dialog box appears. 


I xi 


The Activation Key that you specify must also be used in the module configuration. 


Activation Key: 


Confirm Activation Key: 


Trust state: [Uninitialized 


Close | Help | 
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Step10 Enter the activation key in the Activation Key and Confirm Activation Key fields of the Communication 
dialog box. 


Note Remember this key for future use with MARS. 


Step11 Click Initialize to generate the client SIC DN. 


Result: The client SIC DN is generated and the Communication dialog box closes, returning to the 
OPSEC Application Properties dialog box. The new SIC appears in the DN field. 


Description: Check Point Management Infrastructure 


Secure Internal Communication 


Communication... { iS MeICN=Test_mars100,0=mnat..icudax 


OK Cancel Help 
_Ceneet_| Heb _| 
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Step12 Click Close to close the Communication dialog box. 
Step13 Record the contents of the DN field that appears under Secure Internal Communication. 


This value is used to populate the Client Entity SIC Name field of MARS in Add a Check Point Primary 
Management Station to MARS, page 4-37. 


Tip If possible, you should cut and paste the Secure Internal Communication DN field value into an 
application, such as Notepad, for later use. Transcribing this field is error prone. Use a mouse to select 
the contents of read-only field, and then use Ctrl+Insert to copy the field to memory. You can paste the 
value using Shift+Insert. Be careful to avoid trailing spaces when you paste the value into MARS. 


Step14 Select the CPMI Permissions tab and verify that either Administrator’s credentials or a permissions 
profile with administrative credentials is selected under Login to SmartCenter with. 
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Step 16 


Step 17 
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Click OK to close the OPSEC Application Properties dialog box. 
Click Close to close the Servers and OPSEC Application dialog box. 


Result: The OPSEC Application that represents MARS is defined and associated to the correct host. You 
also have obtained the activation key and client SIC DN for later use in Add a Check Point Primary 
Management Station to MARS, page 4-37. 


Select Policy > Install Database on the main menu. 


Result: This operation updates the remote Check Point components (child enforcement modules), such 
as CMAs, CLMs, log servers, and firewalls. It provides them with the authorization and credentials of 
the MARS Appliance, as an OPSEC component and SIC client. 


Using the Check Point log viewer, you can verify that the OPSEC object was pushed successfully. 


Continue with Obtain the Server Entity SIC Name, page 4-27. 


Obtain the Server Entity SIC Name 


Step 1 


Step 2 
Step 3 
Step 4 


The server SIC DN is one of the shared secrets used to provide non-repudiation during a secure 
communication between a Check Point component and the MARS Appliance. This value is used when 
defining a primary management station in MARS as defined in Add a Check Point Primary Management 
Station to MARS, page 4-37. 


Log in to the correct Check Point user interface using an account with administrative privileges. 


If you are using SmartCenter, use the SmartDashboard for that server. If you are using Provider-1 or 
SiteManager-1 NG FP3 or NG AI (R55), use the SmartDashboard of the CMA. If you are using 
Provider-1 or SiteManager-1 NGX (R60), use the MDG. 


Select Manage > Network Objects on the main menu. 
Select Check Points in the Show list. 
Select the correct Check Point component in the Network objects list. 


Which Check Point component you select depends on which SIC you need and what Check Point system 
you are using. Specifically, you want to obtain SICs for: 


e Each management server to discover configuration settings via CPMI. 
e Each management server to which logs are forwarded by remote components. 


e Each remote log server that does not forward logs to a central management server, either the MDS 
or a SmartCenter. 


Management servers are the following devices: 
e SmartCenter server for standalone SmartCenter and SmartCenter Pro installations. 
e Each CMA of a Provider-1 or SiteManager-1 NG FP3 or NG AI (R55) installation. 
e The MDS of a Provider-1 or SiteManager-1 NGX (R60) installation. 

Log servers are the following devices: 
e SmartCenter server for standalone SmartCenter and SmartCenter Pro installations. 


e Each CLM of a Provider-1 or SiteManager-1 NG FP3 or NG AI (RSS) installation. 
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e The MLM of a Provider-1! or SiteManager-1 NGX (R60) installation. 


Network Objects 


~ Network objects: 


Show: | Check Points ~| More >> 


& Corporate-internalterminal-server 
iy Corporate-VVA-proxy-server 
BM anacemert 
EY Management-b 
B) Remote-1 -gw 


(3 Remote-1-web-server 


Gateway Management Server 


New... | Remove | Edit... | 
Actions... | Help | 


143634 


Step5 Click Edit. 


The Check Point Host - Management dialog box appears, with the General Properties page selected. 


Check Point Host - Management 


General Properties Check Point Host - General Properties 


Topology 
NAT Name: Management 
+) VPN 
+) Logs and Masters IP Address: [172.16.1.200 Get address | 
pares Comment: [Gateway Management Server 
Coo: | i ~] 
Check Point Products 
Version: et Versior 


Type: Check Point Enterprise/Pro Y 


Additional Products: 


F] Configure Servers... 


Secure Internal Communication 


Communication | BN Jen=cp_mamt.c=primary_management..unrgad 
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Step 6 Record the value defined in the DN field under Secure Internal Communication. 


This value is used to populate the Server Entity SIC Name field of MARS in either Add a Check Point 
Primary Management Station to MARS, page 4-37, Manually Add a Child Enforcement Module or Log 
Server to a Check Point Primary Management Station, page 4-41, or Edit Discovered Firewall on a 
Check Point Primary Management Station, page 4-47. 


Step7 Click OK to close the Check Point Host dialog box. 
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For each additional management or log server in this Check Point installation, select that device in the 
Network Objects list, and repeat Step 5 through Step 7. 


Click Close to close the Network Objects dialog box. 
Continue with Select the Access Type for LEA and CPMI Traffic, page 4-29. 


Select the Access Type for LEA and CPMI Traffic 


wy 


Check Point devices use special access types for configuration discovery and event log queries. For 
configuration discovery, the protocol is CPMI. For event log queries, the protocol is LEA. Each of these 
protocols has specific configurable attributes, including whether to use bulk encryption, what cipher to 
use, and what port to use for communications. 


You must understand what the supported settings are so that you can verify the Check Point devices are 
configured correctly. MARS supports only three of the available Check Point authentication mode: 


CLEAR. Indicates that the traffic is neither authenticated nor encrypted. 


SSLCA. Indicates that the communications need to be authenticated and encrypted using an 
symmetric key cipher 


ASYMSSLCA. Indicates that the communications need to be authenticated and encrypted using an 
asymmetric key cipher. 


These access protocols are configured as follows: 


Note 


Typically, the default values should be used unless your Check Point deployment includes CLMs. 


<service> auth_port <port_number> 


This line is required in the fwopsec.conf file. The service value is either LEA_SERVEAR or 
CPMI_SERVER. Two possible values exist for port_number: 0, which indicates an the server is not 
listening for authenticated session requests, and the port number of an authenticated and/or 
encrypted protocol. If the port_number value is 0, you must configure the server to listen for session 
requests in CLEAR mode on a valid port using the <service> port <port_number> settings. 


<service> auth_type <cipher> 


The service value is either LEA_SERVER or CPMI_SERVER. Two possible values are supported 
for cipher: sslca for authentication and encryption using a symmetric key cipher, or asym_sslca for 
authentication and encryption using an asymmetric key cipher. If the auth_port setting is set to 0 
(zero) for this service, then you do not need to specify the auth_type in the fwopsec.conf file. You 
can comment out this line. 


<service> port <port_number> 


This line is required in the fwopsec.conf file. The service value is either LEA_SERVER or 
CPMI_SERVER. The value for port_number must match the port number on which the desired 
network service listens. A port_number of 0 (zero) indicates that log server is not listening in 
CLEAR mode. 


If it is some other number, then any service can come pull the logs without authenticating. For 
LEA_SERVER, you cannot use port 18184, as it is used for encrypted log communications. For 
CPMI_SERVER, you cannot use port 18190. When CLEAR is enabled, authentication is disabled 
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for this port. Any host with access to the Check Point component at this port can pull logs. If you 
chose to enable CLEAR, which is less expensive in terms of overall transaction costs, you define 
policies that restrict access to the MARS Appliance and other know management hosts. 


Note 


Step 1 


Step 2 


Step 3 


Step 4 
Step 5 
Step 6 


Step 7 


Prior to MARS 4.1 and when using Provider-1 or SiteManager-1 NG FP3 or NG AI (R55), you could 
not use SSLCA mode for log retrieval by the MARS Appliance. Instead, you were required to configure 
each CMA and CLM to accept LEA session requests using CLEAR mode. It was unnecessary to 
configure the LEA settings for the MLM. 


The following example indicates that LEA is using ASYMSSLCA-based authentication connecting over 
port 18184 (default), the traffic is encrypted via SSL, and the log server is not listening for requests in 
cleartext. 


LEA_SERVER auth_port 18184 
LEA_SERVER auth_type asym_sslca 
LEA_SERVER port 0 


The following example indicates that the log server is listening for requests in cleartext at port 18187. 
Such requests will be serviced and the sessions will be neither authenticated nor encrypted. 


LEA_SERVER port 18187 


Check Point uses the following default settings: 
e For LEA, SSLCA is the authentication method and communications occur over TCP 18184. 
e For CPMI, SSLCA is the authentication method and communications occur over TCP 18190. 


To review or change the access type settings, follow these steps: 


Log on to the Check Point server. 


For Provider-1 and SiteManager-1, this server is the MDS, MLM, or CLM. Otherwise, it is the 
SmartCenter server. 


Open the fwopsec.coné file found in the subdirectory for each CMA and CLM. 


The following example uses the find command to locate the file. Customer! identifies the CLM. 


[Expert@logger]# find . -name "fwopsec.conf" -print 
./var/opt/CPf£w1l-R55/conf/fwopsec.conf 
./var/opt/CPmds-R55/customers/CustlLog/CPfwl-R55/conf/fwopsec.conf 
[Expert@logger]# cd /var/opt/CPmds-R55/customers/Cust1lLog/CPfw1-R55/conf 


Using a text editor, such as vi or Notepad, edit the fwopsec.conf file and modify the LEA and CPMI 
communication settings as needed. 


Save your changes to the file. 
Repeat Step 2 through Step 4 for each CLM and CMA. 
Restart the Check Point server after the changes are made. 


Result: The CPMI and LEA servers are restarted, which reloads their configuration information, and 
ensures they are listening to the correct ports for session requests. 


Continue with Create and Install Policies, page 4-31. 
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Create and Install Policies 


Step 1 


Step 2 


Step 3 


Step 4 


You must create firewall policies that permit the MARS Appliance to access the relevant ports of the 
Check Point central management server and any remote log servers. The default ports are as follows: 


e TCP port 18190. Used by CPMI to discover configuration settings. 


e TCP port 18210. Used to retrieve the certificate from the Certificate Authority on the SmartCenter, 
MDS, MLM, CMA, or CLM. 


e TCP port 18184. Used to pull security event logs from the log servers, such as the MLM or CLM. 


However, you must use the CPMI and LEA servers settings specified in Select the Access Type for LEA 
and CPMI Traffic, page 4-29. When the policies are defined, you must install them on any firewall 
modules that inspect traffic between the Check Point components and the MARS Appliance. 


If the management server has a Check Point firewall installed, follow these steps: 


Log in to the correct Check Point user interface using an account with administrative privileges. 


If you are using SmartCenter, use the SmartDashboard for that server. If you are using Provider-1 or 
SiteManager-1 NG FP3 or NG AI (R55), use the SmartDashboard of the CMA. If you are using 
Provider-1 or SiteManager-1 NGX, use the MDG. 


If Check Point firewall components reside between the Check Point components (central management 
and log server) and the MARS Appliance monitoring those components, define the security policies that 
allow management and log traffic between those devices. 


If you have enabled CPMI discovery, the service condition must include CMPI. To enable the log access, 
the service list must include FW1_lea. 


Verify that the security policies are set to log. 


The Track column of each rule should display the Log action. To enable logging, right-click the Track 
field of a rule and select Log on the shortcut menu. 


Once you have defined the security policies that enable traffic flows between the Check Point and MARS 
components, select Policy > Install on the main menu. 
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Install Policy 


Installation Targets Advanced Security — 
Corporate-gw 


Select All Clear All Select Targets... 


Installation Mode 
Install on each selected Module independently 


r 


© Install on all selected Modules, if it fails do not install at all 


Revision Control 


IV Create database version 


Name: Firewall¥PN 2005-09-29 07:07:47 
Comment: |Created by | 


Cancel Help 


143630 


Step5 ~—‘In the Install Policy dialog box, verify the Advanced Security check box is selected for each selected 
installation target. 


The target devices should be those firewalls that reside between the Check Point components and the 
MARS Appliance. 


Step6 Click OK to install the policies on the selected devices. 


Result: The security policies on the target firewall devices are updated, enabling CPMI and LEA traffic 
flows between the Check Point components and the MARS Appliance. 


Tip Using the Check Point log viewer, you can verify that the policies were installed successfully. 


Verify Communication Path Between MARS Appliance and Check Point Devices 


You should verify that the MARS Appliance can reach the Check Point devices, including the 
SmartCenter server and the remote log servers. Use the telnet command at CLI of the MARS Appliance 
to verify access to the SmartCenter server and log servers. The ports to check are defined in Select the 
Access Type for LEA and CPMI Traffic, page 4-29. For more information on accessing the CLI, see Log 
In to the Appliance via the Console, page 6-1 of the Install and Setup Guide for Cisco Security 
Monitoring, Analysis, and Response System. 


The command syntax is as follows 


telnet <ip_address> <port_number> 
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If you are unsuccessful, verify the settings of the ports for each Check Point component and verify that 
no firewalls are blocking the traffic. For more information on telnet, see telnet, page A-32 in the Install 
and Setup Guide for Cisco Security Monitoring, Analysis, and Response System. 


Reset the OPSEC Application Certificate of the MARS Appliance 


Step 1 


Step 2 


Step 3 
Step 4 


If you encounter an error when pulling the certificate as part of defining the Check Point devices in the 
MARS web interface, you must reset the certificate before you can attempt to pull it again. This 
procedure details how to reset the certificate, or SIC, associated with the OPSEC Application that is 
associated with the host that represents the MARS Appliance. 


To reset the OPSEC application certificate, follow these steps: 


Log in to the correct Check Point user interface using an account with administrative privileges. 


If you are using SmartCenter, use the SmartDashboard for that server. If you are using Provider-1 or 
SiteManager-1 NG FP3 or NG AI (R55), use the SmartDashboard of the CMA. If you are using 
Provider-1 or SiteManager-1 NGX, use the MDG. 


Select Manage > Servers and OPSEC Applications from the main menu. 
Result: The Servers and OPSEC Application dialog box appears. 
Select OPSEC Applications in the Show list. 


Select the OPSEC application that represents the MARS Appliance in the Servers and OPSEC 
Applications list, and click Edit. 


Result: The OPSEC Application Properties dialog box appears. 
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OPSEC Application Properties - logCsMarsi00 


TT 
= 
[Feescovasco =] 


User defined 


143188 


Step5 = Click the Communication button under Secure Internal Communication. 


Result: The Communication dialog box appears. 


Communication 


xi 
— 
[Urine 
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Step6 Click Reset to reset the certificate. 


Step7 Click Close to close the Communication dialog box. 
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Result: The client SIC DN is generated and the Communication dialog box closes, returning to the 
OPSEC Application Properties dialog box. The new SIC appears in the DN field. 


Step8 Click OK to close the OPSEC Application Properties dialog box. 


Step9 Click Close to close the Servers and OPSEC Application dialog box. 


Result: The OPSEC Application that represents MARS is defined and associated to the correct host. You 
also have obtained the activation key and client SIC DN for later use in Add a Check Point Primary 
Management Station to MARS, page 4-37. 
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Add and Configure Check Point Devices in MARS 


After you identify and bootstrap the Check Point reporting devices and install the policies that enable 
the required traffic flows, you must represent those devices in MARS, which uses this information to 
communicate with the devices. When adding a Check Point device, you add two types of devices: 


Primary management station. The primary management station represents the SmartCenter server 
or CMA that manages other Check Point components. In the web interface, the bases module is 
defined as a software application (Check Point Management Console application) running on a host. 


Child enforcement module. A child enforcement module is a Check Point component, a firewall 
or log server, that is managed by a primary management station. When viewing the Security and 
Monitoring Devices list, child enforcement modules appear as children of the hosts that are running 
the primary management station. 


With these definitions in mind, adding and configuring the Check Point device involves the following: 


1. 


11. 


12. 


13. 


Define a host that represents the Check Point primary management station, specifying the hostname 
and management and reporting IP addresses. 


Define all of the interfaces of the host. 


Add the correct Check Point software application to the host. This application represents the primary 
management station. 


Specify the communication settings for the primary management station. These settings include 
identifying which access types are allowed (CPMI, LEA or both) and the authentication type and 
port to use for each supported access type. 


(Optional) Define the settings for secure communications. If the access communication are not 
conducted in CLEAR, then you must specify the client and server SIC DNs and identify the 
certificate authority. 


(Optional) Define the routes used by the firewall running on the primary management station. If a 
firewall is running on the primary management station, the route information is required to enable 
the path analysis and mitigation features of MARS. 


Discover the child enforcement modules and the configuration settings of the primary management 
station. Discovery of child enforcement modules includes any log servers and firewalls managed by 
the primary management station. MARS discovers configuration settings, such as policies, NAT, 
modules, and clusters, as well as event information, such as traffic logs, SmartDefense events, and 
user authentication events. 


Configure the discovered log servers. To configure these log servers, select the Self option from the 
Log Info page associated with each server, and specify the access type settings. 


Define any log servers not managed by the primary management station. These servers are used by 
one or more of the firewalls that were discovered or by the primary management station. 


Edit each firewall child enforcement module to select a log server. 


(Optional) Specify an SNMP RO community string for each firewall child enforcement module for 
which resource utilization monitoring is desired. 


(Optional) Define the routes used by each firewall child enforcement module. Route information is 
required to enable the path analysis and mitigation features of MARS. 


Click Activate in MARS. 


To add a Check Point device in MARS, you must perform the following procedures: 


Add a Check Point Primary Management Station to MARS, page 4-37 
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e Manually Add a Child Enforcement Module or Log Server to a Check Point Primary Management 
Station, page 4-41 


e Edit Discovered Log Servers on a Check Point Primary Management Station, page 4-45 
e Edit Discovered Firewall on a Check Point Primary Management Station, page 4-47 
e Verify Connectivity Between MARS and Check Point Devices, page 4-52 


If discovery of Check Point configuration settings is not enabled for MARS, you must perform the 
following manual configuration procedures: 


e Manually Add a Child Enforcement Module or Log Server to a Check Point Primary Management 
Station, page 4-41 


e Specify Log Info Settings for a Child Enforcement Module or Log Server, page 4-49 


Before You Begin 


To perform this procedure, you need the following information: 
e A MARS account with Administrative privileges. 


e A Check Point CMA or SmartCenter username and password that has READ access (minimum 
requirement). 


e The client and server SIC DNs. 


e If you are defining a CMA for Provider-1! or SiteManager-1, you must have the virtual IP address 
(VIP) for each CMA and CLM managed by the MDS. 


Add a Check Point Primary Management Station to MARS 


The primary management station represents one of the following: 
e The SmartCenter server in a SmartCenter or SmartCenter Pro installation. 


e¢ ACMA ofa Provider-1 or SiteManager-1 installation. 


Note Check Point 4.1, NG FP1, and NG FP2 devices are not officially supported. They cannot be configured 
to retrieve configuration information using CPMI. However, they can be configured to retrieve logs using 
LEA. To configure one of these devices to work with the MARS, leave the Access IP field blank on the 
host that represents the base platform. 


You must define each individual CMA of a Provider-1 or SiteManager installation, regardless of the 
release and version. 


Step1 Select Admin > System Setup > Security and Monitor Devices > Add. 
Step2 Do one of the following: 
e¢ Select Add SW Security apps on a new host from the Device Type list, and continue with Step 3 


e Select Add SW security apps on existing host from the Device Type list. Select the device to which 
you want to add the software application and click Add. Continue with Step 7. 


Step3 Specify values for the following fields: 
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Step 4 


Step 5 


Step 6 
Step 7 
Step 8 


e¢ Device Name — Enter the name of the device. This name must exactly match the hostname shown 
in the Check Point user interface. MARS maps this name to the reporting IP address. This name is 
used in topology maps, queries, and as the primary management station in the Security and 
Monitoring Device list. 


e Access IP — (Optional) This s address is used to pull from a Check Point device using CPMI, 
enabling MARS to discover settings from this device. This address represents either a virtual IP 
address associated with a CMA or the physical IP address of the SmartCenter server. To learn more 
about the access IP address, its role, and dependencies, see Understanding Access IP, Reporting IP, 
and Interface Settings, page 2-8. 


e Reporting IP — Enter the IP address of the interface in the Check Point server from which MARS 
will pull traffic and audit logs. Check Point audit logs save information regarding user interaction 
with Check Point devices, such as log in and out of the Check Point user interface, initialize or 
revoke certificate, install or uninstall policy, create, modify, and delete objects, etc. No additional 
configuration is needed to turn on audit log on Check Point device. 


This address represents either a virtual IP address associated with a CMA or the physical IP address 
of the SmartCenter server. To learn more about the reporting IP address, its role, and dependencies, 
see Understanding Access IP, Reporting IP, and Interface Settings, page 2-8. 


Under Enter interface information, enter the interface name, IP address, and netmask value of each 
interface in the Check Point server from which configuration information will be discovered and from 
which security event logs will be pulled. 


This address represents either a virtual IP address associated with a CMA or the physical IP address of 
the SmartCenter server. To learn more about the interface settings, its role, and dependencies, see 
Understanding Access IP, Reporting IP, and Interface Settings, page 2-8. 


(Optional) To enable MARS to monitor this device for anomalous resource usage, select Yes from the 
Monitor Resource Usage list. 


Result: MARS monitors the device for anomalous consumption of resources, such as memory and CPU. 
If anomalies are detected, MARS generates an incident. Resource utilization statistics are also used to 
generate reports. For more information, see Configuring Resource Usage Data, page 2-41. 


Click Apply to save these settings. 
Click Next to access the Reporting Applications tab. 
Select the appropriate version of Check Point Opsec from the Select Application list, and click Add. 
The following options are available: 
e CheckPoint Opsec NG FP3. Select this option for Check Point NG FP3 devices. 


e CheckPoint Opsec NG ATI. Select this option for Check Point NG AI (R55) and Check Point NGX 
(R60) devices. 
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% 
| General | Reporting Applications ¥ulnerability Assessment 


Enter reporting application: 


> Device Name: Softie II 


> Select application: [Select one =] 


di CheckPoint Opsec NG AI 
CheckPoint Opsec NG FP3 
| [Device Type 


Cisco ACS 3.x 

Cisco CSA 4.x 

Cisco ICS 1.x 

Enterasys Dragon 6.x 
Entercept Entercept 2.5 
Entercept Entercept 4.0 
Foundstone FoundScan 3.0 
Generic Web Server Generic 
ISS RealSecure 6.5 

ISS RealSecure 7.0 
IntruVert IntruShield 1.5 
McAfee ePO 3,5 

NetScreen IDP 2.1 

Oracle Database Server Generic 


right © 2003, 2005 Cisco Syste 
jhts reserved. 


Snort Snort 2.0 
Symantec Anti Virus 9.x 
Symantec ManHunt 3.x 


ummary :: Incidents :: Query / Reports ::; Rules :: Manag 


143202 


If you entered an address in the Access IP field on the host that represents this primary management 
station, specify values for the following fields: 


e Access Type — This value identifies the authentication method to use for CPMI traffic, which is the 
protocol used to discover configuration information. Select ASYMSSLC, CLEAR, or SSLCA. The 
discovery operation identifies any child enforcement modules managed by this primary management 
station. It also discovers the NAT and ACL information necessary for NAT-based correlation, attack 
path calculation, and mitigation analysis. For more information on the access type, see Select the 
Access Type for LEA and CPMI Traffic, page 4-29. 

Access Information 

(Optional: for NAT-related session correlation, 

attack path calculation, and mitigation 

enter access information] Secure Internal Communication Information 

> “Access Type: SSLCA 5 “Certificate: Select Certificate ¥ 

> *Access Port: (Default:18190) 
Name: 
*Password: _———s| *Server Entity SIC [ ] 
Name: 
Reporting Information SNMP RO Community: [ 
=> 


*LEA Access Type:[ssica x 


143205 


Info Discover Cancel Submit 


Access Port — Verify that the port number corresponds to the value specified in the 
CPMI_SERVER auth_port line of the fwopsec.coné file. The default authentication method for 
configuration discovery is SSLCA and data is passed on port 18190. For more information on this 
setting, see Select the Access Type for LEA and CPMI Traffic, page 4-29. 
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Step 10 


Step 11 


Step 12 


Step 13 


Step 14 


Step 15 


e Login — Identifies the Check Point administrative account to be used to discover configuration 
settings. 


e Password — Identifies the password asscociated with the Login account. 
Specify values for the following fields: 


e LEA Access Type — If a log server is running on this primary management station select 
ASYMSSLC, CLEAR, or SSLCA. You must have entered an address in the Reporting IP field on 
the host that represents this primary management station. This value identifies the authentication 
method to use for LEA traffic, which is the protocol used to pull security logs from the log server. 
For more information on the access type, see Select the Access Type for LEA and CPMI Traffic, 
page 4-29. 


e LEA Port — Verify that the port number corresponds to the value specified in the LEA_SERVER 
auth_port line of the fwopsec.coné file. The default authentication method for configuration 
discovery is SSLCA and data is passed on port 18184. For more information on this setting, see 
Select the Access Type for LEA and CPMI Traffic, page 4-29. 


If this device uses SSLCA or ASYMSSLCA as an authentication method, specify values for the 
following fields (Otherwise, the authentication method is CLEAR. Skip toStep 12.): 


e Certificate — Either select the previously defined server from the list or click Add to define a new 
certificate authority and continue with Add a Check Point Certificate Server, page 4-44. 


e Client SIC Name — Enter the SIC DN of the OPSEC application for the MARS Appliance. This 
value was obtained in Define an OPSEC Application that Represents MARS, page 4-24. 


e Server SIC Name — Enter the SIC DN for this primary management station. This value was 
obtained in Obtain the Server Entity SIC Name, page 4-27. Typically, this value is the SIC DN of 
the SmartCenter server or of the CMA. In the case of Provider-1 and SiteManager-1 NGX (R60), 
this value is the SIC DN of the MDS that manages the CMA. 


(Optional) To enable MARS to retrieve MIB objects for this reporting device, enter the device’s 
read-only community string in the SNMP RO Community field. 


Before you can specify the SNMP RO string, you must define an access IP address on host that represents 
the primary management station and you must configure the Access Information settings on the primary 
management station. MARS uses the SNMP RO string to perform resource utilization monitoring. 
Currently, it is not used for configuration or log discovery. 


(Optional) To enable MARS to monitor this device for anomalous resource usage, select Yes from the 
Monitor Resource Usage list. 


Before you can enable this feature, you must provide a SNMP RO Community string. 


Result: MARS monitors the device for anomalous consumption of resources, such as memory and CPU. 
If anomalies are detected, MARS generates an incident. Resource utilization statistics are also used to 
generate reports. For more information, see Configuring Resource Usage Data, page 2-41. 


(Optional) To specify the route information for a firewall running on this primary management station, 
continue with Define Route Information for Check Point Firewall Modules, page 4-47. 


(Optional) If you defined an access IP and selected and configured an access type, click Discover to 
determine the device settings. 


Result: If the username and password are correct and the MARS Appliance is configured as an 
administrative host for the device, the “Discovery is done.” dialog box appears when the discovery 
operation completes. Otherwise, an error message appears. After the initial pull, the MARS Appliance 
pulls based on the schedule that you define. For more information, see Scheduling Topology Updates, 
page 2-39. 
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Note 


Step 16 


Step 17 


Step 18 


Sometimes, the discovery operation times out, in which case you should try again. At other times, a 
message appears that states the discovery is taking a long time and that you should proceed to performing 
other tasks in MARS. 


To add this device to the MARS database and continue adding firewall modules manually, click Submit. 


Result: The submit operation records the changes in the database tables. However, it does not load the 
changes into working memory of the MARS Appliance. The activate operation loads submitted changes 
into working memory. 


Do one of the following: 


e To manually define the child enforcement modules that are managed by this primary management 
station, continue with Manually Add a Child Enforcement Module or Log Server to a Check Point 
Primary Management Station, page 4-41. 


e To edit the settings of the discovered child enforcement modules, continue with Edit Discovered 
Firewall on a Check Point Primary Management Station, page 4-47. 


Click Activate. 


Result: Once the MARS Appliance is activated, it connects to the Check Point log modules and retrieves 
the traffic and audit logs. MARS also begins to sessionize events generated by this device and evaluate 
those events using the defined inspection and drop rules. Any events published by the device to MARS 
before activation can be queried using the reporting IP address of the device as a match criterion. For 

more information on the activate action, see Activate the Reporting and Mitigation Devices, page 2-27. 


Manually Add a Child Enforcement Module or Log Server to a Check Point Primary Management 


Station 


If you have not enabled configuration discovery on the primary management station or if one or more of 
the managed firewalls uses a log server that is not managed by the primary management station, you can 
manually define firewalls or log servers. Your goal should be to represent all of the firewalls managed 
by this primary management station and all log servers used by those firewalls and the primary 
management station. While MARS does not discover configuration settings of the firewalls, it uses the 
defined information to discover topology, calculate attack paths, and identify preferred mitigation points 
in the network. 


For example, if you are defining a primary management station that represents a CMA, you must define 
the CLM associated with that CMA. Any firewalls managed under that CMA may either act as their own 
log servers, publish information to the CLM, or publish information to a MLM. In the case of the later, 
you must define that relationship by defining the firewalls and then specifying which log servers pull 
their traffic and audit logs. First, however, must also define the MLM settings, as it is a log server that 
external to the perspective of the CMA, and it cannot be referred by a firewall until it has been defined. 
The CLM, however, would be considered part of the CMA (assuming the reporting IP and LEA settings 
are specified), so you would not define a separate child enforcement module to represent it. Instead, you 
would select the Management option in the Log Info dialog for firewalls that use the CLM as their log 
server. For more information on selecting the log server option, see Specify Log Info Settings for a Child 
Enforcement Module or Log Server, page 4-49. 


To manually define a child enforcement module that is managed by the primary management station or 
a log server to which either the primary management station or a child enforcement module publishes 
its audit and security logs, follow these steps: 
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Step1 Select Admin > System Setup > Security and Monitor Devices. 


Step2 From the Security and Monitor Devices list, select the host that represents the primary management 
station and click Edit. 


Such devices have CheckPoint Management Console as an entry in the Device Type column. 


Step3 Click Next to access the Reporting Applications tab. 


% 
| General | Reporting Applications ¥Yulnerability Assessment Info 


Enter reporting application: 


> Device Name: DEV-CMA 


> Select application: | select one 


| |DeviceType 


[- CheckPoint Management Console 


143632 


Step4 Select the CheckPoint Management Console check box in the Device Type list and click Edit. 


The Access Information page appears. 


Access Information 
(Optional: for NAT-related session correlation, 
attack path calculation, and mitigation 


enter access information] Secure Internal Communication Information 
> *Access Type: [ssuca =] *Certificate: [testServer = 
> *Access Port: [i190 | (Default:18190) 

*Login: *Client Entity SIC Name: 


*Password: 


*Server Entity SIC Name: [tectServer 


Reporting Information SNMP RO Community: | 
> *LEA Access Type: [ssuca x] 


*LEA Port: 18184 | (Default:16184) Route Info 


Firewall & Log Server Settings 


Add Edit Delete Log Info Route Info 


Info Discover Cancel Submit 
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Step5 Click Add under Firewall & Log Server Settings. 
Result: The list of available hosts appears. 


Step6 Do one of the following: 
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e Select the host on which the child enforcement module is running, click Change Existing, and 
continue with Step 7 


Result: A page with a read-only device name appears, prompting you to specify the SNMP RO 
Community string. 


> *Device Name: Test host 


> SNMP RO Community: 


Add Interface Remove Interface 


Name: IP Address: Network Mask: 


I [ethero | [292 }{zes }fs]fa3_| [255 ]f255 ]{25s ]f2ss ] 


Cancel Submit 


143623 


e Click Add New to define a new host, and continue with Step 7 


Result: A page appears, prompting you to specify device name and SNMP RO Community string. 


> SNMP RO Community:[ 


Add Interface Remove Interface 


Name: IP Address: Network Mask: 


r ee | | | 


i 
co 
me 

Cancel Submit |F 


Enter the name of the child enforcement module or log server in the Device Name field. 


MARS maps this name to the IP address specified in the interfaces. This name is used in topology maps, 


queries, and appears in the Children column of the base Check Point module in the Security and 
Monitoring Device list. 


(Optional) To enable MARS to retrieve MIB objects for this reporting device, enter the child 
enforcement module’s read-only community string in the SNMP RO Community field. 
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Step 9 


Step 10 
Step 11 


Step 12 


Step 13 


Step 14 


Step 15 


Step 16 


Before you can specify the SNMP RO string, you must define an access IP address on host that represents 
the primary management station. MARS uses the SNMP RO string to read MIBs related to a reporting 
device’s CPU usage, network usage, and device anomaly data and to discover device and network 
settings. 


Under Enter interface information, enter the interface name, IP address, and netmask value of each 
interface installed in the child enforcement module or log server. 


These interfaces include the ones from which the configuration information will be discovered and 
security event logs will be pulled. To learn more about the interface settings, its role, and dependencies, 
see Understanding Access IP, Reporting IP, and Interface Settings, page 2-8. 


Click Submit to add this module to the primary management station. 


(Optional) To specify the route information for a firewall child enforcement module, continue with 
Define Route Information for Check Point Firewall Modules, page 4-47. 


If the child enforcement module does not propagate its logs to the primary management station or if you 
are defining a log server that is not managed by this primary management station, you must specify 
where its logs are stored. Continue with Specify Log Info Settings for a Child Enforcement Module or 
Log Server, page 4-49. 


Repeat Step 5 through Step 12 for each child enforcement module that is managed by this primary 
management station and each log server that is used by the primary management station or child 
enforcement modules. 


To add this device to the MARS database, click Submit. 


Result: The submit operation records the changes in the database tables. However, it does not load the 
changes into working memory of the MARS Appliance. The activate operation loads submitted changes 
into working memory. 


Click Done to close the Reporting Applications tab and return to the Security and Monitoring Devices 
list. 


Click Activate. 


Result: Once the MARS Appliance is activated, it connects to the Check Point log modules and retrieves 
the traffic and audit logs. MARS also begins to sessionize events generated by this device and its 
modules and evaluate those events using the defined inspection and drop rules. Any events published by 
the device to MARS before activation can be queried using the reporting IP address of the device as a 
match criterion. For more information on the activate action, see Activate the Reporting and Mitigation 
Devices, page 2-27. 


Add a Check Point Certificate Server 


When defining a Check Point module that uses secured communications, you must identify the 
certificate sever that authenticates the SICs provided by the client and the server. Typically, a 
SmartCenter server or the CMA has its own certificate server, however, your configuration may use a 
central server. If that is the case, you must define the certificate server as part of a defining a base or 
child enforcement module. 


Note 


This procedure assumes you have been refer to it, and that you are in the middle of defining a primary 
management station or child enforcement module. 


To define a certificate server, follow these steps: 
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Step 2 


Step 3 


Step 4 


Check Point Devices il 


Click Add to define the settings for the certificate authority. 


Cisco SYSTEMS 


Standalone: LC20-Doc v4.1 


CheckPoint Certificate 


Certificate Authority IP Address: 
Client SIC Name: 

Activation Key: 

Port: 


Pull Certificate 
Copyright © 2003, 2005 Cisco Systems, Inc. 


All rights reserved, 


Specify values for the following fields: 


e Certificate Authority IP Address — Typically, this IP address is the physical IP address of the 
SmartCenter server or the virtual IP address of the CMA. In the case of Provider-1 and 
SiteManager-1 NGX (R60), this IP address represents the physical IP address of the MDS that 
manages the CMA. 


e Client SIC Name — Enter the SIC DN of the OPSEC application for the MARS Appliance. This 
value was obtained in Define an OPSEC Application that Represents MARS, page 4-24. 


e Activation Key — This value was also provided in Define an OPSEC Application that Represents 
MARS, page 4-24. 


Click Pull Certificate. 
Result: A message box appears stating “Discovery is done.” 


A certificate can be pulled only once for an OPSEC Application. If for any reason the pull operation fails, 
you must reset the certificate using the CheckPoint SmartDashboard. For more information, see Reset 
the OPSEC Application Certificate of the MARS Appliance, page 4-33. 


Click Close. 


Edit Discovered Log Servers on a Check Point Primary Management Station 


After performing a discovery operation, you must edit each discovered log servers. The purpose of 
editing this log server is to identify that it is its own log server and to provide the SIC communication 
settings. 


To edit a discovered log server, follow these steps: 
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Step 1 Under Firewall & Log Server Settings, select the check box next to the desired log server, and click Log 
Info. 


Step2 Select Self. 


( Management *Reporting 
IP: 


Certificate: 
Cc Log Server 


Client SIC 
Name: 
Server SIC 
@ Self Name: 
*Logging 
Access 
Type: 
*Logging 
Access 
Port: 


(Default:18184) 


wo 
8 
Cancel Submit |9 


Step3 Specify values for the following fields: 


¢ Reporting IP — Enter the IP address of the interface in the log server from which MARS will pull 
security event logs. This address represents either a virtual IP address associated with a CLM, an 
MLM, or another log server. To learn more about the reporting IP address, its role, and 
dependencies, see Understanding Access IP, Reporting IP, and Interface Settings, page 2-8. 


e Logging Access Type — This value identifies the authentication method to use for LEA traffic, 
which is the protocol used to pull security logs from the log server. Select ASYMSSLC, CLEAR, 
or SSLCA, For more information on the access type and port, see Select the Access Type for LEA 
and CPMI Traffic, page 4-29. 


e Logging Port — Verify that the port number in the corresponds to the value specified in the 
LEA_SERVER auth_port line of the fwopsec.conf file on this log server. The default authentication 
method for configuration discovery is SSLCA and data is passed on port 18184. 


Step4 If this log server uses SSLCA or ASYMSSLCA as an authentication method, specify values for the 
following fields (Otherwise, the authentication method is CLEAR. Skip to Step 5): 


e Certificate — Either select the previously defined server from the list or click Add to define a new 
certificate authority and continue with Add a Check Point Certificate Server, page 4-44. 


e Client SIC Name — Enter the SIC DN of the OPSEC application for the MARS Appliance. This 
value was obtained in Define an OPSEC Application that Represents MARS, page 4-24. 


e Server SIC Name — Enter the SIC DN for the child enforcement module. This value was obtained 
in Obtain the Server Entity SIC Name, page 4-27. Typically, this value is the SIC DN of the 
SmartCenter server or of the CMA. In the case of Provider-1 and SiteManager-1 NGX (R60), this 
value is the SIC DN of the MDS that manages the CMA. 


Step5 Click Submit to save your changes to this log server. 


Step6 Repeat Step | through Step 5 for each discovered log server. 
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Edit Discovered Firewall on a Check Point Primary Management Station 


After performing a discovery operation, you must edit any discovered firewalls. You must specify which 
log server the firewall uses, define the route information, and if you want to monitor resource utilization, 
you must specify the SNMP RO community string. 


Note 


When editing a Check Point Firewall, never select a Check Point Firewall from the Security and 
Monitoring Devices list. Instead, select the Check Point Management Console that acts as the primary 
management station for that firewall. 


Note 


Step 1 
Step 2 
Step 3 


Step 4 
Step 5 


Step 6 


Step 7 


You must configure the discovered log servers and define any log servers not managed by the primary 
management station before editing the discovered firewalls. To configure the discovered log servers, see 
Edit Discovered Log Servers on a Check Point Primary Management Station, page 4-45. To manually 
define log servers, see Manually Add a Child Enforcement Module or Log Server to a Check Point 
Primary Management Station, page 4-41. 


To edit a discovered firewall, follow these steps: 


Under Firewall & Log Server Settings, select the check box next to the desired firewall. 
Click Edit. 


(Optional) To enable MARS to retrieve MIB objects for this reporting device, enter the child 
enforcement module’s read-only community string in the SNMP RO Community field. 


Before you can specify the SNMP RO string, you must define an access IP address on host that represents 
the primary management station. MARS uses the SNMP RO string to read MIBs related to a reporting 
device’s CPU usage, network usage, and device anomaly data and to discover device and network 
settings. 


Click Submit. 


To define the route settings for this firewall, continue with Define Route Information for Check Point 
Firewall Modules, page 4-47. 


To select the log server used by this firewall, continue with Specify Log Info Settings for a Child 
Enforcement Module or Log Server, page 4-49. 


Repeat Step | through Step 6 for each discovered firewall. 


Define Route Information for Check Point Firewall Modules 


To perform attack path analysis and to provide suggested mitigation configurations, MARS must 
understand the static routes that are defined on a firewall module. This requirement is true for firewalls 
running on the primary management station as well as for each firewall child enforcement module 
managed by the primary management station. To provide this information, you must define the routes 
manually in the MARS web interface. You will need a list of the routes for all interfaces in the firewall 
before you attempt to enter this information. 
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Step 2 


Step 3 
Step 4 
Step 5 


You do not need to specify which interface the route is associated with. MARS derives this information 
based on the interface settings you have specified for the host. 


To define the static routes used by a firewall, follow these steps: 


Do one of the following: 


e To specify the route information for the primary management station, click Route Info on the 
primary management station page. 


e To specify the route information for a firewall child enforcement module, select the server under 
Device Type, click Route Info. 


Result: The Route Information dialog box appears. 


> Device Name: Test host 


> “Destination Address: a | | | 
> *Destination Mask: | ee; | | 
> Next Hop Address: a 


> Metric: [ 


143628 


Cancel Submit 


Specify values for the following fields: 
e¢ Destination Address — Enter the internal or external destination network address 
e¢ Destination Mask — Enter the corresponding network mask value. 
e¢ Next Hop Address — Enter the IP address of the default gateway. 


¢ Metric — Identifies the priority for using a specific route. When routing network packets, a gateway 
device uses the rule with the most specific network within the rule's definition. Only in cases where 
two routing rules have the same network is the metric used to determine which rule is applied. If 
they are the same, the lowest metric value takes priority. If no routing rule exists, the network packet 
is dropped, and if the gateway is not detected (dead), the network packet is dropped. 


A metric is a measurement of the cost of a route based on the number of hops (hop count) to the 
network on which a specific host resides. Hop count refers to the number of networks that a network 
packet must traverse, including the destination network, before it reaches its final destination. 
Because the hop count includes the destination network, all directly connected networks have a 
metric of |. For the metric value, specify a number between | and 15. 


Click Submit to add the route to the list of routes 
Repeat ¢ through Step 3 for each route defined on the firewall. 


Click Close to return to the Access Information page. 
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Specify Log Info Settings for a Child Enforcement Module or Log Server 


Step 1 


There are two occasions when you must define the log settings manually: 


e If you do not discover the settings of the primary management station, which does discover the log 
settings. 


e Ifthe child enforcement module does not propagate its logs up to the primary management station. 
Three options exist for manually specifying the log settings: 


e Management. Identifies that the child enforcement module propagates it logs up to the primary 
management station, the MLM or the SmartCenter server. You do not specify these settings; they are 
derived from the settings on the primary management station. However, the option is available if the 
configuration of a child enforcement module changes. If the primary management station is the log 
server for a child enforcement module, the log server information is populated when you perform 
the test connectivity operation. 


Figure 4-1 Log Information Published to Primary Management Station 
@ Management Reporting IP 10. 
Certificate: test 
Client SIC Name: 
Cc Log Server Server SIC Name: 


Logging Access Type: 
Logging Access Port: 


Cc Self 


143625 


Cancel | Submit 


e Log Server. Identifies that another log server, such as a CLM, is acting as the log server for this 
child enforcement module. You must either select a pre-defined log server or define the settings for 
a new one and select it. 


e Self. Identifies that the child enforcement module is acting as its own log server. In this case, you 
must specify the communication settings required to pull the logs from that module or server. 


To specify the log server settings of a child enforcement module manually, follow these steps: 


(Firewall only) If a child enforcement module does not propagate its log information to the primary 
management station, then select that child enforcement module under Device Type, click Log Info, and 
do one of the following: 


e To specify that the child enforcement module is acting as its own log server, select Self and continue 
with Step 3, omitting the Device Name field. 
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Cc Management *R rti i ( ( 
reporting [JL] 


Certificate: | Select Certificate 
© LogServer client sic 


Name: 


Self Server SIC 
(f Se 


Name: 
*Logging [SsLca | 
Access 
Type: 
*Logging [isia4 (Default:18184) 
Access 

Port: 


wo 
N 
wo 
Cancel Submit |9 


e To specify an alternate log server, select Log Server, and continue with Step 2. 
Result: The Log Information dialog box appears, and the desired option is selected. 
Step2 Do one of the following: 


e Select a predefined log server from the Select list, click Submit, and continue with Step 5. 


¢ Management [Select [i 


@ Log Server 


C Self 


Cancel Submit 


143624 


e Click Add to define a new log server. 


*Device Name: 
*Reporting IP: 
Certificate: 


Client SIC Name: 


Server SIC Name: 


*Logging Access 
Type: 


SSLCA i? 
*Logging Access 18184 (Default;18184} 


Port: 
a 
a 
[ submit ]g 


Step3 Specify values for the following fields: 


¢ Device Name — Enter the name of the log server. MARS maps this name to the reporting IP address. 
This name is used in topology maps, queries, and as the primary management station in the Security 
and Monitoring Device list. For devices that support the discovery operation, such as routers and 
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Check Point Devices Hil 


firewalls, MARS renames this field’s value to match the name discovered in the device 
configuration, which typically uses the hostname.domain format. For devices that cannot be 
discovered, such as Windows and Linux hosts and host applications, MARS uses the provided value. 


¢ Reporting IP —Enter the IP address of the interface in the log server from which MARS will pull 
security event logs. This address represents either a virtual IP address associated with a CLM, an 
MLM, or another log server. To learn more about the reporting IP address, its role, and 
dependencies, see Understanding Access IP, Reporting IP, and Interface Settings, page 2-8. 


e Logging Access Type — This value identifies the authentication method to use for LEA traffic, 
which is the protocol used to pull security logs from the log server. Select ASYMSSLC, CLEAR, 
or SSLCA, For more information on the access type, see Select the Access Type for LEA and CPMI 
Traffic, page 4-29. 


e Logging Port — Verify that the port number in the corresponds to the value specified in the 
LEA_SERVER auth_port line of the fwopsec. conf file on this log server. The default authentication 
method for configuration discovery is SSLCA and data is passed on port 18184. For more 
information on this setting, see Select the Access Type for LEA and CPMI Traffic, page 4-29. 


If this log server uses SSLCA or ASYMSSLCA as an authentication method specify values for the 
following fields (Otherwise, CLEAR is the authentication method for Access Type and LEA Access 
Type, and you should skip to Step 5): 


e Certificate — Either select the previously defined server from the list or click Add to define a new 
certificate authority and continue with Add a Check Point Certificate Server, page 4-44. 


e Client SIC Name — Enter the SIC DN of the OPSEC application for the MARS Appliance. This 
value was obtained in Define an OPSEC Application that Represents MARS, page 4-24. 


e Server SIC Name — Enter the SIC DN for the child enforcement module. This value was obtained 
in Obtain the Server Entity SIC Name, page 4-27. Typically, this value is the SIC DN of the 
SmartCenter server or of the CMA. In the case of Provider-1 and SiteManager-1 NGX (R60), this 
value is the SIC DN of the MDS that manages the CMA. 


To add this child enforcement module to the primary management station, click Submit. 
To add the primary management station to the MARS database, click Submit. 


Result: The submit operation records the changes in the database tables. However, it does not load the 
changes into working memory of the MARS Appliance. The activate operation loads submitted changes 
into working memory. 


Click Done to close the Reporting Applications tab and return to the Security and Monitoring Devices 
list. 


Click Activate. 


Result: Once the MARS Appliance is activated, it connects to the Check Point log modules and retrieves 
the traffic and audit logs. MARS also begins to sessionize events generated by this device and its 
modules and evaluate those events using the defined inspection and drop rules. Any events published by 
the device to MARS before activation can be queried using the reporting IP address of the device as a 
match criterion. For more information on the activate action, see Activate the Reporting and Mitigation 
Devices, page 2-27. 
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Verify Connectivity Between MARS and Check Point Devices 


After defining the Check Point device and clicking Activate in the MARS web interface, the MARS 
Appliance connects to the log servers and pulls the traffic and audit logs stored on them. You can verify 
that these transactions are successful using the following method: 


e Perform an ad hoc query for Event Types/Sessions specify to the Check Point primary management 
station. 


Result: The netstat command should display two connections per log server. 


Remove a Firewall or Log Server from a Check Point Primary Management Station 
If the configuration of your network changes so that a firewall or log server is no longer managed by the 
primary management station under which it is defined, you must remove the child enforcement module. 


To remove a child enforcement module from the primary management station, follow these steps: 


Step1 Select Admin > System Setup > Security and Monitor Devices. 


Step2 From the Security and Monitor Devices list, select the host that represents the primary management 
station of the Check Point server and click Edit. 


Such devices have CheckPoint Management Console as an entry in the Device Type column. 


Step3 = Click Next to access the Reporting Applications tab. 


gy 
| General | Reporting Applications ¥ulnerability Assessment Info 
Enter reporting application: 
> Device Name: DEV-CMA4 
> Select application: | Select one ¥| | add 
Edit Remove 
| | Device Type 
[~ CheckPoint Management Console 


143632 


Step4 Select CheckPoint Management Console from the Device Type list and click Edit. 
The Access Information page appears. 

Step5 = Under Firewall & Log Server Settings, check the box next to the child enforcement module that you want 
to remove. 

Step6 Click Remove. 


Result: The Confirmation screen appears. 
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Click Submit to remove the child enforcement module from the primary management station. 


Troubleshooting MARS and Check Point 


The following information can be used to troubleshoot communicate issues between the MARS 
Appliance and Check Point components. 


e To view attack information by user, run a query where the device is a Check Point device. 


e If you attempt to discover the certificate and it returns to the CheckPoint Certificate screen instead 
of displaying the “Discovery done.” message box, then the discover operation failed. The likely 
cause is an incorrect SIC value. 


S 
Note A certificate can be pulled only once for an OPSEC Application. If for any reason the pull 


operation fails, you must reset the certificate using the CheckPoint SmartDashboard. For more 
information, see Reset the OPSEC Application Certificate of the MARS Appliance, page 4-33. 


e If the device discovery operation fails, click the View Error button for a detailed error message. 
Common reasons for failure of device discovery are as follows: 


e client SIC DN name or server SIC DN name is incorrect. Use copy and paste from SmartDashboard 
to avoid erroneous entry. 


e Invalid Certificate used. 


e Invalid user name, password, or both used. Verify that the credentials provided for the Access IP 
match an Check Point account with administrative privileges. 


e Unsupported version of Check Point. (Discovery works only with NG FP3 and above. Internally we 
have tested up to Version R60) 


e Invalid authentication method used. The default method is SSLCA. Check the twopsec. cont file to 
determine which method is used. CS-MARS currently support only three authentication methods for 
CPMI communication: SSLCA, ASYM_SSLCA and CLEAR. For more information on specifying 
these settings, see Select the Access Type for LEA and CPMI Traffic, page 4-29. 


e Invalid access port. Default port for secured CPMI-based communication is TCP 18180. Check the 
fwopsec.coné to verify the configured port. 


e The MARS Appliance does not have access to port 18190, or an alternate specified in fwopsec. conf 
for CPMI. At the CLI of the MARS Appliance, use the telnet command to test the access port. For 
more information on telnet, see Verify Communication Path Between MARS Appliance and Check 
Point Devices, page 4-32. 


e The policy database was not installed after creating OPSEC Application in the SmartDashboard. 


e Firewall policies were not created and installed that permitted the MARS Appliance to connect to 
the Check Point primary management station. For information, see Create and Install Policies, page 
4-31. 


For additional Check Point discovery-related debug information, use the pnlog command at the CLI of 
the MARS Appliance. You can use the cpdebug attribute to specify appropriate debug level. Level 9 
presents all debug messages. You can view the debug messages using the pnlog showlog cpdebug 
command at the CLI. For more information on pnlog, see pnlog, page A-18 in the Jnstall and Setup 
Guide for Cisco Security Monitoring, Analysis, and Response System. 
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Configuring VPN Devices 


VPN devices provide MARS with information about remote hosts, login in requests and denials, and 
access times. With this data, MARS can provide end-to-end attack path analysis and identify the VPN 
device through which attacks are launched. 


This chapter explains how to bootstrap and add the following VPN device to MARS: 
e Cisco VPN 3000 Concentrator, page 5-1 


Cisco VPN 3000 Concentrator 


MARS can receive and process events from the Cisco VPN 3000 Concentrator, versions 4.0.1 and 4.7. 
To enable communications, you must perform two tasks: 


e Bootstrap the VPN 3000 Concentrator, page 5-1 
e Add the VPN 3000 Concentrator to MARS, page 5-2 


Bootstrap the VPN 3000 Concentrator 


To configure a Cisco VPN 3000 Concentrator to generate and publish events to the MARS Appliance, 
you must verify that the correct events are generated in the correct format, and you must direct the Cisco 
VPN 3000 Concentrator to publish syslog events to the MARS Appliance. 


To configure Cisco VPN 3000 Concentrator to send syslog events to MARS, follow these steps: 


Step 1 Open your browser and log in to the Cisco VPN 3000 Concentrator Series Manager. 


Step2 From the tree on the left, select Configuration > System > Events > General. 
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Configuration | System | Events | General 


This section lets you configure default event handling. 


Save Log on Wrap [— Check to save the event log to a file on wrap. 
Save Log Format [Muttiine =] Select the format of the saved log files. 
eireered ahi Check to automatically FTP the saved log to a remote destination. 
E-mail Source Address || Enter the e-mail address that appears in the From: field. 
Syslog Format [Original = Select the format of Syslog messages. 
Events to Log [Severities 1-5 ¥] Select the events to enter in the log. 
Events to Console [Severities 1-3 ¥] Select the events to display on the console. 
Events to Syslog [Severities 1-5 ¥] Select the events to send to a Syslog Server. 
Events to E-mail | None x Select the events to send to an E-mail Recipient. é 
Events to Trap [Severities 1-3 ¥] Select the events to send to an SNMP Trap Destination. 8 


Step3 —- Verify that the Syslog Format is Original. 
Step4 Select Severities 1-5 in the Events to Syslog field. 
Step5 From the tree on the left, select Configuration > System > Events > Syslog Servers. 


Step6 Click Add to define a target syslog server. 


Configuration | System | Events | Syslog Servers | Add 


Add a syslog server. 
Syslog Server [cs-mars| Enter the IP address or hostname of the syslog server. 
Port [51 4 Enter the port used by the syslog server. 
Facility Local? >| Select the syslog facility tag for events sent to this server. 


Cancel | 
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Step7 =‘ In the Syslog Server field, enter the IP address or hostname of the MARS Appliance. 
Step8 Click Add to save the syslog server settings. 


Step9 = Click Save in the top-right corner to save all changes. 


Add the VPN 3000 Concentrator to MARS 


To add the VPN 3000 Concentrator to MARS, follow these steps: 


Step1 Select Admin > Security and Monitor Devices > Add. 


Step2 Select either Cisco VPN Concentrator 4.0.1 or Cisco VPN Concentrator 4.7 from the Device Type 
list. 
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Step 3 
Step 4 
Step 5 
Step 6 
Step 7 


Step 8 
Step 9 


evice Type: | Cisco VPN Concentrator 4.0.3 = 
*Device Name: [LY 
Access IP: a 
Reporting IP: a | | 


*Access Type: 


SNMP RO Community: 


Monitor Resource [uo | 


Usage: 


Cisco VPN 3000 Concentrator Ml 
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Enter the name of the VPN Concentrator in the Device Name field. 


Enter the IP address used to administer the VPN Concentrator in the Access IP field. 


Enter the IP address from which the syslog messages are sent to MARS in the Reporting IP field. 
Select SNMP from the Access Type list. 


(Optional) To enable MARS to retrieve MIB objects for this Concentrator, enter the device’s read-only 
community string in the SNMP RO Community field. 


MARS uses the SNMP RO string to read MIBs related to the reporting device’s CPU usage and other 
device anomaly data. 


Click Discover. 
Click Submit. 
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Configuring Network-based IDS and IPS Devices 


Network intrusion detection and intrusion preventions systems are a critical source for identifying active 
attacks to MARS. 


This chapter explains how to bootstrap and add the following network-based IDS and IPS devices to 
MARS: 


e Cisco IDS 3.1 Sensors, page 6-1 

e Cisco IDS 4.0 and IPS 5.x Sensors, page 6-5 
e Cisco IPS Modules, page 6-9 

e ISS Site Protector, page 6-13 

e ISS RealSecure 6.5 and 7.0, page 6-17 

e IntruVert IntruShield, page 6-22 

e Snort 2.0, page 6-28 

e Symantec ManHunt, page 6-29 

e NetScreen IDP 2.1, page 6-31 

e Enterasys Dragon 6.x, page 6-33 


Cisco IDS 3.1 Sensors 


Before you add the Cisco IDS 3.1 device, make sure that you have configured the Cisco IDS device for 
the MARS to retrieve the device configuration. The device configuration would be used for mapping of 
the logs received by MARS. 


When configuring the IDS device to send logs to the MARS, you must use the exact name of the MARS 
Appliance. To determine the name of the appliance, select Admin > System Setup > Configuration 
Information and review the value in the Name field. 


Configure Sensors Running IDS 3.1 


Step 1 Log in to the Cisco IDS device. 
Step2 Change to directory that has all the configurations files that need to be edited: 


cd /usr/nr/etc 
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Step3 You need to edit 4 files (organizations, hosts, routes and destinations) that are in this directory. 
In the organizations file add a line indicating your organization name or grouping; 
e.g., 1 protego 


where 1 is the item number followed by the organization name protego. If there is already item in 
this file, simply increase the item number (has to be unique). 


Figure 6-1 Add MARS Information to Cisco IDS 3.1 Organizations File 
| £3 10.1.1.5 - default - SSH Secure Shell Wok 


File Edit View Window Help 


H4n 82 BRE AHA DS OW 


§] Quick Connect () Profiles 


Generated: Sun Jul 21 19:28:55 2002 4 
# Template: £:\Program Files\Cisco Systems\Cisco Secure Pol 
icy Manager\bin\templates\common\etc\organizations.template 

# Sensor Version: 3.1(2)525 

# Sensor OS: Sun0S 


1 protego 


SSH2 - 3des-chc - hmac-md5 - none 
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In the hosts file add a line indicating your MARS appliances’ name associated to the organization that 
was previously added in the organizations file; 


e.g., 2001.1 pnmars.protego 


where 2001.1 is a unique item number followed by the MARS appliances’ name and organization 
name protego. If there is already items in this file, simply increase the item number (has to be 


unique). 
Figure 6-2 Add MARS Information to Cisco IDS 3.1 Hosts File 
10.1.1.5 - default - SSH Secure Shell Jeg 


File Edit View Window Help 


HSA SBS BER KAHD SD OW 
| Quick Connect (5) Profiles 


Generated: Wed Sep 18 20:17:16 2002 4) 
# Template: C:\Program Files\Cisco Systems\Cisco Secure 
Policy Manager\bin\templates\common\etc\hosts.template 

# Sensor Version: 3.1(2)525 

# Sensor OS: Sun0dS 


1200. 
1200. 
1001. 
1400. 


localhost 
Sensor3.protego 
NTSVR1.protego 
sunshine.protego 


1600. 
1700. 
1800. 


pnguard.protego 
pnmars50.protego 
pluto.protego 


1 
i 
1 
1 
1500.1 pncop.protego 
cf 
1 
1 


= 
|SSH2 - 3des-cbc - hmac-md5 -r 
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In the routes file add a line indicating your MARS appliances’ name and its IP address; 
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e.g., pnmars.protego 1 10.1.1.10 45000 1 5 


Cisco IDS3.1Sensors Hi 


where pnmars.protego is the MARS’s name (with organizations’ name) followed by | then the 


MARS appliances’ IP address. 


The 45000 is the port number that the IDS will use to send its logs to MARS. Add a | follows by a5 at 
the end of this line (these numbers are not used by MARS). 


Figure 6-3 Add MARS Information to Cisco IDS 3.1 Routes File 
10.1.1.5 - default - SSH Secure Shell Joleg 


File Edit View Window Help 
24a 82 BEE & HO % OW 
£1] Quick Connect (5) Profiles 


B Generated: Wed Sep 18 20:17:16 2002 

# Template: C:\Program Files\Cisco Systems\Cisco Secure 
Policy Manager\bin\templates\common\etc\routes. template 
# Sensor Version: 3.1(2)525 

# Sensor OS: Sun0S 


NISVR1.protego 1 10.1.1.20 45000 1 5 
Sensor3.protego 1 10.1.1.5 45000 15 
sunshine.protego 1 10.1.1.12 45000 1 5 
pnlistener.protego 1 10.1.1.141 45000 15 
pnguard.protego 1 10.1.1.132 45000 15 
pnguard.protego 2 10.1.1.137 45000 15 
pnmarsS0.protego 1 10.1.1.252 45000 15 
pluto.protego 1 10.1.1.131 45000 1 5 
athens.protego 1 10.1.1.18 45000 1 5 
pnmars50 1.protego 1 10.1.2.1 45000 15 
pnmarsS0 2.protego 1 10.1.2.2 45000 1 5 


Connected to 10.1.1.5 SSH2 - 3des-cbc - hmac-md5 -no 7 


a) 


L = 
\v| 
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In the destinations file add a line indicating your MARS appliances’ name (as defined in the routes file) 
the client process that the appliance is using to listen for events from the sensor (in this case smid), and 
the list of log types you want sent to the appliance as a comma separated list: 


e.g., pnmars.protego smid ERRORS, EVENTS, 


COMMANDS 


where pnmars.protego is the MARS’s name (with organizations’ name) followed by smid and the list 
of log types that the loggerd daemon will publish to the appliance. 
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Step 4 


Figure 6-4 Add MARS Information to Cisco IDS 3.1 Destinations File 
| £3 10.1.1.5 - default - SSH Secure Shell aX) 


File Edit View Window Help 
2S4R SS BLO MHDS OW 


| €] Quick Connect (5 Profiles 


Generated: Wed Sep 18 20:17:16 2002 \& 
# Template: C:\Program Files\Cisco Systems\Cisco Secure Policy 
Manager\bin\templates\common\etc\destinations. template 

# Sensor Version: 3.1(2)S25 

# Sensor OS: Sun0S 


Sensor3.protejgo loggerd 1 ERRORS, EVENTS, COMMANDS 
NISVR1.proteg2 smid 1 ERRORS, EVENTS, COMMANDS 
sunshine.prot2go smid 1 ERRORS, EVENTS, COMMANDS 
pnguard.protejo smid 1 ERRORS, EVENTS, COMMANDS 
pnmars50.prot2go smid 1 ERRORS, EVENTS, COMMANDS 
pluto.protego smid 1 ERRORS, EVENTS, COMMANDS 
athens.proteg? smid 1 ERRORS, EVENTS, COMMANDS 

& pnmars50_1.protego smid 1 ERRORS, EVENTS, COMMANDS 
9 pnmarsSO 2.protego smid 1 ERRORS, EVENTS, COMMANDS 
10 pnmars100_33.protego smid 1 ERRORS, EVENTS, COMMANDS 
11 pnmars50_4.protego smid 1 ERRORS, EVENTS, COMMANDS 
12 pnlistener.protego smid 1 ERRORS, EVENTS, COMMANDS 


SOW ee WN be 
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SSH2 - 3des-cbc - hmac-md5 - none 


Connected to 10,1.1.5 


Once you’ve edited these four files (organizations, hosts, routes, and destinations), reboot the sensor 
using the following commands: 


a. nrstop 


b. nstart 


Add and Configure a Cisco IDS 3.1 Device in MARS 


Step 1 
Step 2 
Step 3 


Step 4 
Step 5 


Step 6 
Step 7 


To add and configure a Cisco IDS device in MARS, follow these steps: 


Click Admin > System Setup > Security and Monitor Devices > Add. 
Select Cisco IDS 3.1 from the Device Type list. 

Enter the hostname of the sensor in the Device Name field. 

The Device Name value must be identical to the configured sensor name. 
Enter the administrative IP address in the Access IP field. 

Enter the administrative IP address in the Reporting IP field. 

The Reporting IP address is the same address as the administrative IP address. 
Select either SSH or TELNET. 

Enter “netrangr” as the Login and its Password. 


When adding a Cisco IDS 3.1 device, use the netrangr username or some other username that is not the 
root login for the sensor. Using the root login causes MARS to fail to parse the login prompt correctly, 
which in turn, cause the Test Connectivity to fail. 
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Step 8 


Step 9 
Step 10 


Cisco IDS 4.0 and IPS 5.x Sensors 


Figure 6-5 Configure Cisco IDS 3.1 
Device Type: Cisco IDS 3.1 
> *Device [HQ-NIDSi 
Name: = 


> *Access IP: fio Jz }{z _} {200 | 
md oe 10 }W1 1 — |4100 


> *Access SSH (¥] 
Type: = 
Login: [netrangr | 
Password: 
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For attack path calculation and mitigation, add networks into the Monitored Networks field. 
a. Click the Select a Network or Define a Network radio button. 

e In the Select a Network list, click a network. 

e Inthe Define a Network field, enter its network IP and network mask information. 

b. Click Add to move the selected networks into the Monitored Networks field. 
(Optional) To discover the device settings, click Discover. 
Click Submit. 


Cisco IDS 4.0 and IPS 5.x Sensors 


Adding a Cisco IDS or IPS network sensor to MARS involves two parts: 
1. Bootstrap the Sensor, page 6-5 

2. Add and Configure a Cisco IDS or IPS Device in MARS, page 6-6 
The following topic supports Cisco IDS and IPS devices: 

e View Detailed Event Data for Cisco IPS Devices, page 6-9 


Note 


If you’ve imported your sensor definitions using the seed file format, as specified in Load Devices From 


the Seed File, page 2-24, you must define the networks monitored by the sensor. 


Bootstrap the Sensor 


Preparing a sensor to be monitored by MARS involves two steps: 
e Enable the Access Protocol on the Sensor, page 6-6 


e Enable the Correct Signatures and Actions, page 6-6 
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Enable the Access Protocol on the Sensor 


The configuration of the sensor depends on the version of the software that is running on the sensor. The 
following topics identify the requirements of each version: 


e Cisco IDS 4.x Software, page 6-6 
e Cisco IPS 5.x Software, page 6-6 


Cisco IDS 4.x Software 


For Cisco IDS 4.x devices, MARS pulls the logs using RDEP over SSL. Therefore, MARS must have 
HTTPS access to the sensor. To prepare the sensor, you must enable the HTTP server on the sensor, 
enable TLS to allow HTTPS access, and make sure that the IP address of MARS is defined as an allowed 
host, one that can access the sensor and pull events. If the sensors have been configured to allow access 
from limited hosts or subnets on the network, you can use the accessList ipAddress ip_address 
netmask command to enable this access. 


Cisco IPS 5.x Software 


For Cisco IPS 5.x devices, MARS pulls the logs using SDEE over SSL. Therefore, MARS must have 
HTTPS access to the sensor. To prepare the sensor, you must enable the HTTP server on the sensor, 
enable TLS to allow HTTPS access, and make sure that the IP address of MARS is defined as an allowed 
host, one that can access the sensor and pull events. If the sensors have been configured to allow access 
from limited hosts or subnets on the network, you can use the access-list ip_address/netmask 
command to enable this access. 


Enable the Correct Signatures and Actions 


If the signature actions are correctly configured, MARS can display the trigger packet information for 
the first event that fires a signature on a Cisco IDS or IPS device. MARS is also able to pull the IP log 
data from Cisco IDS and IPS devices, however, this operation is system intensive. Therefore, you should 
select the set of signatures that generate IP log data carefully. 


When configuring the active signatures on a Cisco IDS or IPS device, you must specify the alert action 
and the action that generates the desired data: 


e To view trigger packets, you must enable the “produce-verbose-alert” action. 


e To view IP logs, you must enable the alert or “produce-verbose-alert” action and the 
“log-pair-packets” action. 


A 


Caution Configuring IP logging and verbose alerts on the sensor is system intensive and does affect the 
performance of your sensor. In addition, it affects the performance of your MARS Appliance. Because 
of these effects, you be cautious in configuring signatures to generate IP logs. 


Add and Configure a Cisco IDS or IPS Device in MARS 


To add and configure a Cisco IDS or IPS device in MARS, follow these steps: 


Step1 Click Admin > System Setup > Security and Monitor Devices > Add. 
Step2. Do one of the following: 
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Cisco IDS 4.0 and IPS 5.x Sensors 


e Select Cisco IDS 4.0 from the Device Type list. 


Figure 6-6 Configure Cisco IDS 4.0 


Device Type: Cisco IDS 4.0 


> *Device lids4.corp.protegonetwd 
Name: 


>  Repurine fio |i |i fas _] 


> *Access SSL 
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e Select Cisco IPS 5.x from the Device Type list. 


Figure 6-7 Configure Cisco IPS 5.x 
Device Type: [Cisco IPS 5.x | 
> Reporting 1P: ee 
> *Access Type: SSL 
Port: 
> Monitor Resource NO + 
Usage: 
Pull IP Logs: NO © 


(Optional: for attack path calculation and mitigation enter monitoring networks information] 


> Monitored Networks: 


<I Add 
C Select a Network: 
[10.0.0,0/255.0.0,0( n-10,0,0,0/8 } z] 


c Define a Network: 


Network IP; | | ; 
Mask: a | | | 


| <@ Back | | Test Connectivity | Submit 


Step3 Enter the hostname of the sensor in the Device Name field. 
The Device Name value must be identical to the configured sensor name. 


Step 4 Enter the administrative IP address in the Access IP field. 
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Step 5 


Step 6 


Step7 
Step 8 


S 


Enter the administrative IP address in the Reporting IP field. 
The Reporting IP address is the same address as the administrative IP address. 


In the Login field, enter the username associated with the administrative account that will be used to 
access the reporting device. 


In the Password field, enter the password associated with the username specified in the Login field. 


In the Port field, enter the TCP port on which the webserver running on the sensor listens. The default 
HTTPS port is 443. 


Note 


Step 9 
Step 10 


Step 11 
Step 12 


While it is possible to configure HTTP only, MARS requires HTTPS. 


To pull the IP logs from the sensor, select Yes in the Pull IP Logs box. 


For attack path calculation and mitigation, specify the networks being monitored by the sensor. Do one 
of the following: 


To manually define the networks, select the Define a Network radio button. 

a. Enter the network address in the Network IP field. 

b. Enter the corresponding network mask value in the Mask field. 

c. Click Add to move the specified network into the Monitored Networks field. 

d. Repeat as needed. 

To select the networks that are attached to the device, click the Select a Network radio button. 
a. Select a network from in the Select a Network list. 

b. Click Add to move the selected network into the Monitored Networks field. 

c. Repeat as needed. 

To verify the configuration, click Test Connectivity. 


Click Submit. 


Specify the Monitored Networks for Cisco IPS or IDS Device Imported from a 


Seed File 


Step 1 
Step 2 


Step 3 


After you import a Cisco IPS or IDS device into MARS using a seed file, you must define the networks 
that are monitored by that sensor. 


To define the networks monitored by a sensor, follow these steps: 


Click Admin > System Setup > Security and Monitor Devices. 


Select the check box next to the Cisco IPS or IDS device that was imported using a seed file. and click 
Edit. 


To specify the networks being monitored by the sensor, do one of the following: 
To manually define the networks, select the Define a Network radio button. 
a. Enter the network address in the Network IP field. 


b. Enter the corresponding network mask value in the Mask field. 
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Cisco IPS Modules Mi 


c. Click Add to move the specified network into the Monitored Networks field. 

d. Repeat as needed. 

To select the networks that are attached to the device, click the Select a Network radio button. 
a. Select a network from in the Select a Network list. 

b. Click Add to move the selected network into the Monitored Networks field. 

c. Repeat as needed. 

To save your changes, click Submit. 


To enable MARS to start sessionizing events from this module, click Activate. 


View Detailed Event Data for Cisco IPS Devices 


You can view the trigger packets and IP log data associated with incidents reported by Cisco IDS 4.x and 
Cisco IPS 5.x devices, whether they are sensor appliances or modules. This information is useful when 
an in-depth understanding of the attack method is desired. MARS includes two event types that focus on 
the these two data types: 


e Trigger packet data. Identifies the data that was being transmitted on the network the instant an 
alarm was detected. You can use this information to help diagnose the nature of an attack. The 
trigger packet provides a single data packet—the data packet that caused the alarm to fire. 


e Packet data. Identifies the data that was being transmitted on the network the instant an alarm was 
detected. You can use this information to help diagnose the nature of an attack. Although the amount 
of data contained in an IP log varies based on sensor configuration, by default an IP log contains 30 
seconds of packet data. To view this data, you must enable the Pull IP Logs option on the Cisco IPS 
device under Admin > System Setup > Security and Monitor Devices. 


Note 


wy 


MARS does not collect this data for Cisco IDS 3.x devices. 


For the correct signature settings required to generate this data, see Enable the Correct Signatures and 
Actions, page 6-6. 


If the IP log feature is enable for the reporting Cisco IPS device, these event types are combined as part 
of the incident data. You can view this data by drilling down in an incident, expanding the desired event 
type (either Packet Data or Trigger Packet Data), selecting an event, and clicking on the RAW Events 
for this Session icon under the Reporting Device column of that event. The source, destination, and other 
data displayed for these events matches that of the original alert. In addition, this data appears 
hexadecimal and binary format. 


Note 


The trigger packet and IP log data is stored using a base64-encoded format in the MARS database. 
Therefore, keyword search does not work on it if you just provide the search string. 


Cisco IPS Modules 


MARS can monitor Cisco IPS modules installed in Cisco switches and Cisco ASA appliances. To 
prepare these modules, you must perform the following tasks: 
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e Define the base module, either the router, switch, or Cisco ASA, as defined in Cisco Router Devices, 
page 3-1, Cisco Switch Devices, page 3-9, and Cisco Firewall Devices (PIX, ASA, and FWSM), 
page 4-1. 


e Bootstrap the base module to enable SDEE traffic on the Cisco IPS module, to forward events to the 
MARS Appliance, and to enable MARS to access the SDEE events stored on the modules. Module 
access enables MARS to retrieve trigger packets and IP log information. 


e Add the IPS feature set t the base module previously defined in the web interface. 
This section contains the following topics: 

e Enable DTM Support, page 6-10 

e Enable SDEE on the Cisco IOS Device with an IPS Module, page 6-10 

e Add an IPS Module to a Cisco Switch or Cisco ASA, page 6-11 


Enable DTM Support 


To support DTM, you must configure your IPS module as follows: 
e Purchase or enable the IOS IPS feature set. 
e Enable HTTPS for SDEE. 


e Enable SSH to discover settings, which is the method recommended over Telnet. 


Enable SDEE on the Cisco IOS Device with an IPS Module 


In addition to enabling either Telnet or SSH for configuration discovery on a Cisco IOS device, you must 
also enable SDEE on the device that supports IPS module. SDEE is used to publish events to MARS 
about signatures that have fired. 


To enable SDEE protocol on the Cisco IOS device that supports IPS module, perform the following 
steps: 


Step 1 Log in to the Cisco IOS device using the enable password. 
Step2 Enter the following commands to enable MARS to retrieve the events from the IPS module: 


Router (config)#ip http secure-server 
Router (config)#ip ips notify sdee 
Router (config) #ip sdee subscriptions 3 
Router (config) #ip sdee events 1000 
Router (config)#no ip ips notify log 


wy 


Note The “no ips notify log” causes the IPS modules to stop sending IPS events over syslog. 
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Add an IPS Module to a Cisco Switch or Cisco ASA 


Step 1 
Step 2 


Step 3 


Step 4 


You can enable in-line IPS functionality and signature detection in multi-purpose Cisco platforms. You 
can identify an IDS-M2 running in a Cisco Switch or an ASA-SSM running in a Cisco ASA. To represent 
either of these modules, you must define the settings for the module as part of the base platform, which 
must be previously defined under Admin > System Setup > Security and Monitor Devices. 


To add an IPS module to a Cisco Switch of Cisco ASA, follow these steps: 


Click Admin > System Setup > Security and Monitor Devices. 


From the list of devices, select the Cisco switch or Cisco ASA to which you want to add the IPS module 
and click Edit. 


Click Add Module. 


> *Reporting IP: ) 


SNMP RO Community: 


143172 


| Cancel | | Submit 


Select Cisco IPS 5.x in the Device Type list. 


For Cisco switches, you can also add a Cisco IPS 4.0 module or an IDS 3.1 module. You configure these 
modules just as you would a standalone sensor. For instructions on configuring these modules, refer to 
Cisco IDS 3.1 Sensors, page 6-1 and Cisco IDS 4.0 and IPS 5.x Sensors, page 6-5. 
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Figure 6-8 Configure Cisco IPS 5.x 
Device Type: [Cisco IPS 5.x | 
> *Device Name: 
> Reporting IP: Ce | | | 
> *Access Type: SSL 
Login: 
Password: 
Port: 


Usage: 
Pull IP Logs: 


443 
> Monitor Resource Jno x] 
[no x | 


(Optional: for attack path calculation and mitigation enter monitoring networks information] 


> Monitored Networks: 


<I Add 
C Select a Network: 
[10.0.0.0/255.0.0,0( n-10,0.0.0/6 } z] 


C Define a Network: 


Network IP; a | | | 
Mask: a | | 


143176 


@ Back | | Test Connectivity | Submit 


Step5 Enter the hostname of the sensor in the Device Name field. 
Step6 Enter the administrative IP address in the Reporting IP field. 
Step7 The Reporting IP address is the same address as the administrative IP address. 


Step 8 In the Login field, enter the username associated with the administrative account that will be used to 
access the reporting device. 


Step9 In the Password field, enter the password associated with the username specified in the Login field. 
Step10 In the Port field, enter the TCP port on which the webserver running on the sensor listens. 


The default HTTPS port is 443. 


Note While it is possible to configure HTTP only, MARS requires HTTPS. 


Step11 For attack path calculation and mitigation, specify the networks being monitored by the sensor. Do one 
of the following: 


To manually define the networks, select the Define a Network radio button. 
a. Enter the network address in the Network IP field. 
b. Enter the corresponding network mask value in the Mask field. 


c. Click Add to move the specified network into the Monitored Networks field. 
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Step 12 
Step 13 
Step 14 


ISS Site Protector Mi 


d. Repeat as needed. 

To select the networks that are attached to the device, click the Select a Network radio button. 
a. Select a network from in the Select a Network list. 

b. Click Add to move the selected network into the Monitored Networks field. 

c. Repeat as needed. 

Click Test Connectivity to verify the configuration. 

To save your changes, click Submit. 


To enable MARS to start sessionizing events from this module, click Activate. 


ISS Site Protector 


wy 


Note 


wy 


This topic describes how to use Site Protector to configure the ISS NIDS and HIDS; Site Protector is not 
a device type that can be monitored or used as an aggregation point for ISS event data from the 

perspective of MARS. MARS cannot parse event data from Site Protector, unless you develop a custom 
event parser for each event type as described in Adding User Defined Log Parser Templates, page 15-1. 


MARS supports ISS NIDS and HIDS event retrieval via SNMP. However, when configuring ISS 
RealSecure sensors (NIDS) and hosts (HIDS), you must configure each active signature to send an alert 
to the MARS Appliance. This task can be very tedious as it must be done for each sensor and after each 
signature upgrade, as it resets the redirect configuration. One approach to simplifying this task is to use 
the ISS Site Protector management console to define these changes globally and apply them to each 
sensor. 


ISS Site Protector 2.0 allows you to centrally manage SNMP alert destinations, such as the MARS 
Appliance, for group policies. You can then push these group policies to all desired host and network 
sensors. For each ISS signature update, you must specify the MARS Appliance as an SNMP alert 
destination before you apply the downloaded signatures to sensors using Site Protector. 


Note 


Step 1 


By default, the group policy response configuration is supported only on Proventia G400 and G2000 
models. For all other models, including the G100 mentioned, a firmware upgrade is required. See the 
documentation that came with ISS Site Protector for more information. 


To perform the major configuration steps required to use Site Protector to forward the SNMP alerts 
generated by sensors to MARS Appliance, follow these steps: 


Using the Add Sensor Wizard, register the sensor to Site Protector Console. 


Other methods exist for registering sensors in Site Protector. For more information on using the Wizard 
as well as these other methods, see Chapter 9, Registering Software Managed by SiteProtector, on page 
105 at the following URL: 


http://documents.iss.net/literature/SiteProtector/SPUserGuideforSecurity Managers20SP52.pdf 
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| sensor Name | Host | status | version | availabe | 


Proventia G-Series (Next Generation) issProventia 0.1.1.215 | Active 1.2 (XPU 1.55) 


e Ungrouped Assets 


{} Command Jobs 


153989 


Step2 Right-click the sensor to edit, and click Edit Settings on the shortcut menu. 


© Site Manager 


Proventia G-Sericuathentatt = = = : Geiel.215 | Active 1.2 (XPU 1.55) 
e Ungrouped Assets 


lext Generation) 


The Edit Settings dialog appears. 
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Step 3 


Step 4 


ISS Site Protector 


Edit Proventia G-Series (Next Generation) Settings for Sensor: ‘issProventia@10.1.1.215° 


& Firewall 

rd Connection Events 

> « Trons Events 

§ User Defined Events 

R Security Events 
Response Objects 

["] Protection Domains 

fj Global Tuning Parameters 

QB Update Settings 
G-Series 

oS 


Uy Local Tuning Parameters 


Soy USAGE 


IMipGtie Exports. 


6 Frew! | Ott 2 
i Connection Events | Cf fhasor2 


LR Securty Events | 


7 


141.012 j 


141.012 ; 
441.012 ; 


isco 


Create a new SNMP response that sends messages to the IP address of the MARS Appliance: 


a. Select Response Objects from the settings tree. 


b. Select the SNMP tab. 


c. Click Add to create a new SNMP response object using the IP address of the MARS Appliance. 


Edit Proventia G-Series (Next Generation) Settings for Sensor: ‘issProventia@10.1.1.215° 


& Firewall 

Connection Events 
> « Trons Events 
6 User Defined Events 

ecurity Events 
ts 

f°] Protection Domains 
fj Global Tuning Parameters 


QB Update Settings 
G-Series 
EHS 10.1.4.215 


=| Local Tuning Parameters 


public 


Select the Security Events to configure new SNMP destination. 
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* Edit Proventia G-Series (Next Generation) Settings for Sensor: ‘issProventia@10.1.1.215' 


Connection Events 
—.¢ Trons Events 
+ § User Defined Events 


to Regpones Objects 
}—[[] Protection Domains cc = 
—[-] Global Tuning Parameters l | | Tagname | I | 
— Gace Settings a a 
EL G-Series | 
| | HTML_XSS_Attemy ics 
ES 10.1.1.215 = = High 
Ug Local Tuning Parameters = =e up High 
High 
High 
Hig igh 
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a. Select Security Events under the sensor folder. 
b. Select the required security events from the Security Events tab. 
The Group By button allows you to group policies using any number of parameters. 


S 


Note You can also select policies and edit them at the group level. 


c. Click Edit to configure SNMP response of all the selected policies. 
Step5 Select the MARS Appliance on SNMP tab. 
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* Edit Security Events 


—|_eraiea name | 
pars ost 


153992 


a. Enable all the security events by selecting the Enabled checkbox located at the top of the Edit 
Security Events dialog box. 


a. Select the SNMP tab under Responses, and then select the Enabled checkbox next to the name of 
MARS Appliance created in Step 3. 


a. Click OK. 


The security events and updated response target are applied to the selected sensor during the next 
synchronization. 


ISS RealSecure 6.5 and 7.0 


To configure ISS RealSecure, you must perform the following four tasks: 
1. Prepare each ISS sensor as follows: 
e Edit the common.policy files to point to the MARS Appliance as an SNMP target. 


e Modify the current .policy files to configure each signature so that the SNMP notification is 
a default response when triggered. 


e Edit the response.policy files to specify the IP of the SNMP manager (MARS Appliance) and 
the community string. 
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e Restart the ISS daemon for the changes to take effect. 
For more information, see Configure ISS RealSecure to Send SNMP Traps to MARS, page 6-18. 


2. Add the ISS sensor to MARS as a network-based IDS device. For more information, see Add an ISS 
RealSecure Device as a NIDS, page 6-19. 


3. Click Activate to enable proper processing of received events. 


Configure ISS RealSecure to Send SNMP Traps to MARS 


To configure an ISS RealSecure sensor, follow these steps: 


Step 1 Log into the sensor. 


Step 2 Locate the common. policy files in these directories: 


Microsoft Windows 
Program Files\ISS\issSensors\server_sensor_1 
Program Files\ISS\issSensors\network_sensor_1 


Linux 

/opt/ISS/issSensors/server_sensor_1 

/opt/ISS/issSensors/network_sensor_1 
Step 3 Open the common. policy files in a text editor. 
Step4 Change the line that reads: 


Manager =S 


to: 


Manager =S <MARS’s IP address> 


If MARS Appliance’s IP address is NATed, you may need to use the NATed address. If you use the 
MARS Appliance’s IP address as the destination IP address, make sure the SNMP trap can reach MARS 
Appliance. 


Step5 Save these edited files and exit the editor. 


Step 6 Locate the current.policy files in these directories: 


Microsoft Windows 
Program Files\ISS\issSensors\server_sensor_1 
Program Files\ISS\issSensors\network_sensor_1 


Linux 
/opt/ISS/issSensors/server_sensor_1 
/opt/ISS/issSensors/network_sensor_1 


Step7 Open the current .policy files in a text editor. 


Edit each signature to have SNMP as one of its responses, and set the choice for SNMP trap as default. 
For example, in this original signature: 


[\template\features\AOLIM File Xfer\Response\]; 
[\template\features\AOLIM File Xfer\Response\DISPLAY\] ; 
Choice =S Default; 
[\template\features\AOLIM_ File Xfer\Response\LOGDB\]; 
Choice =S LogWithoutRaw; 


Insert the following bolded lines to make it look similar to the following: 
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Step 8 
Step 9 


Step 10 


Step 11 
Step 12 


ISS RealSecure 6.5 and7.0 Mi 


[\template\features\AOLIM File Xfer\Response\]; 
[\template\features\AOLIM File Xfer\Response\DISPLAY\] ; 
Choice =S Default; 
[\template\features\AOLIM File Xfer\Response\SNMP\]; 
Choice =S Default; 
[\template\features\AOLIM_ File Xfer\Response\LOGDB\]; 
Choice =S LogWithoutRaw; 


Save these edited files and exit the editor. 


Locate the response. policy files in these directories: 


Microsoft Windows 
Program Files\ISS\RealSecure SiteProtector\Console 


Linux 
/opt/ISS/RealSecure SiteProtector/Console 


Edit the response.policy files to specify the IP of the SNMP manager (MARS Appliance) and the 
community string: 


SMTP_HOST =S ; 


addr_1 =S ; 
[\Response\SNMP\]; 
[\Response\SNMP\Default\]; 
Manager =S ; 

Community =S public; 


to: 


Manager =S <MARS’s IP address> ; 
Community = S <string> public; 


If MARS Appliance’s IP address is NATed, you may need to use the NATed address. If you use the 
MARS Appliance’s IP address as the destination IP address, make sure the SNMP trap can reach MARS 
Appliance. 


Save these edited files and exit the editor. 

Restart the ISS daemon. 
e For sensors installed on Microsoft Windows, restart it in the Services menu. 
e For sensors installed on Linux, run: 


/etc/init.d/RealSecure stop 
/etc/init.d/RealSecure start 


Add an ISS RealSecure Device as a NIDS 


Step 1 
Step 2 


Step 3 
Step 4 
Step 5 


Click Admin > System Setup > Security and Monitor Devices > Add. 


From the Device Type list, select Add SW Security apps on a new host or Add SW security apps on 
existing host. 


Enter the Device Name. 
Click Apply. 
Click on Reporting Applications tab. 
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Step6 From the Select Application list, select RealSecure (6.5 or 7.0). 
Step7 Click Add. 
Step8 Click the NIDS radio button, if it is not already selected. 


Figure 6-9 Configure ISS Real Secure NIDS 


> @ NIDS ¢ HIDS 


[Optional: for attack path calculation and mitigation enter monitoring networks information] 


> Monitored Networks: 


( Select a Network: 
0/2 > 0.0( n- /16 
[Remove |] | 10.1.0.0/255.255.0.0( n-10.1.0.0/16 ) v] 


@ Define a Network: 


Network IP:| || i || 


Mask: a a: | [] 
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Step9 For attack path calculation and mitigation, specify the networks being monitored by the sensor. Do one 
of the following: 


To manually define the networks, select the Define a Network radio button. 
a. Enter the network address in the Network IP field. 
b. Enter the corresponding network mask value in the Mask field. 
c. Click Add to move the specified network into the Monitored Networks field. 
d. Repeat as needed. 
To select the networks that are attached to the device, click the Select a Network radio button. 
a. Select a network from in the Select a Network list. 
b. Click Add to move the selected network into the Monitored Networks field. 
c. Repeat as needed. 
Step10 To save your changes, click Submit. 


Step11. To enable MARS to start sessionizing events from this module, click Activate. 


Add an ISS RealSecure Device as a HIDS 


Step1 Click Admin > System Setup > Security and Monitor Devices > Add. 


Step2 From the Device Type list, select Add SW Security apps on a new host or Add SW security apps on 
existing host. 


Step3 Enter the Device Name. 
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Step4 = Click Apply. 

Step5 Click on Reporting Applications tab. 

Step6 From the Select Application list, select RealSecure (6.5 or 7.0). 
Step7 Click Add. 

Step8 Click the HIDS radio button. 


Figure 6-10 Configure ISS Real Secure HIDS 


+ ¢ NIDS ¢ HIDS 


To add HIDS RealSecure, select the radio button and submit, then 
add interfaces in the General Tab. 


Step9 Click Submit. 


Step10 For multiple interfaces, click on General Tab, and add the new interfaces’ name, IP address, and 
network mask. 


Figure 6-11 Adding Multiple Interfaces 


Device Type: Edit host with security applications 


g 
Reporting Applications Vulnerability Assessment Info 


*Device Name: 

Access IP: | | | 

Reporting IP: | | | 

Operating System:| Generic [¥] 


Enter interface information: 


Add Interface Remove Interface/IP 


Name: IP Address: Network Mask: 


T" Jetho 10 ffl Hee 4103 | [255 }{255 }40 He Add IP/Network Mask 
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Step11 Click Apply. 
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IntruVert IntruShield 


To configure IntruVert IntruShield in MARS, you must perform the following tasks: 


1. Generate CSV file that identifies each of the IntruShield senor hosts by logging into the database to 
which IntruShield Manager writes and performing and saving a database query. 


2. Configure the IntruShield Manager to send SNMP traps to the MARS Appliance 
3. Define a host that represents the management console (IntruVert Manger) in MARS web interface. 


4. From that host in the MARS web interface, import the IntruShield sensor seed file to identify the 
IntruVert sensors running on other hosts. 


The following sections provide details on performing each of these tasks: 
e Extracting Intruvert Sensor Information from the IntruShield Manager, page 6-22 
e Configure IntruShield Version 1.5 to Send SNMP traps to MARS, page 6-23 
e Configure IntruShield Version 1.8 to Send SNMP Traps to MARS, page 6-23 
e Add and Configure an IntruShield Manager and its Sensors in MARS, page 6-25 


Extracting Intruvert Sensor Information from the IntruShield Manager 


IntruVert sensor information is saved in a database on the IntruShield Manager host. When you configure 
the MARS to add Intruvert sensors, you can manually add the mapping of each Intruvert sensor name or 
you can extract them as a seed file from the database on the Intruvert Manager. 


wy 


Note The instructions apply for Intruvert IntruShield version 1.5. IntruVert supports both MySQL and Oracle. 


To create a CSV file for IntruVert IntruShield 1.5, follow these steps: 


Step 1 Log in to the database. 
Step2 Perform the query: 


use lf; select name, ip_address from iv_sensor where ip_address is not 
NULL; 


Step3 Store the query result into a file, remove the header, trailer, and separator lines, and edit the result to a 
CSV format. 


For example, the query result could be: 


| name | ip_address | 

$o--------- HH poco nH + 

| intruvert | 0A010134 | 

| intruvert1 | 0A010135 | 

$o---------H- foo -n- nH + 

2 row in set (0.00 sec) 

You would then edit the above file to appear as: 

intruvert,0A010134 

intruvert1,0A010135 
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Step4 Save the edited CSV file, move the file to an FTP server from which you can load the seed file using the 
MARS web interface. 


Configure IntruShield Version 1.5 to Send SNMP traps to MARS 


Step 1 Log in to the IntruShield Manager version 1.5. 
Step2 Click Configure. 
Step3 —_—In the Resource Tree, click My Company. 
Step4 = Click the Forwarding tab. 
Step5 Inthe Add SNMP Server field, enter: 
a. Target Server IP Address: Enter MARS’s IP address as it appears to IntruShield. 
b. Target Server Port Number: Enter MARS’s port number 162. 
c. SNMP Version: 1 
d. Check the Forward Alerts box. 
e. Select the For this and child admin domains radio button. 
f. Select the severity from the list. Cisco recommends selecting High and Medium severity. 
g. Check the Forward Faults box. 
h. Select the severity from the list. Cisco recommends selecting Error and above severity. 


Step6 Click Save and exit the program. 


Configure IntruShield Version 1.8 to Send SNMP Traps to MARS 


Step 1 Log in to the IntruShield Manager version 1.8. 
Step2 Click Configure. 

Step3 —_—In the Resource Tree, click My Company. 
Step4 Click the Alert Notification tab. 

Step5 = Click the SNMP Forwarder sub-tab. 
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Figure 6-12 IntruShield SNMP Forwarder Configuration 


Fault Notification 


Admin Domain 


View Details Email 


Syslog Forwarder Pager | Script 


a 
ie 
c | ney Target Server Target Server SNMP 
w ; Manager IP Address Port Number version _—*Alert Forwarding 
= Policies = : 2 5 
For this and children admin domain for 
s E-& sensors 10.1.1.132 162 1 All alerts. 
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—- 10.1.1.12 162 1 For this admin domain only for ALL 
<< ore alerts. 
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5b mare alerts. 
9, 
10.1.1.134 162 1 For this admin domain only for ALL 
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_ alerts. 
ifs For this and children admin domain for 
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For this and children admin domain for 
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~ For this and children admin domain for 
10.1.1.212 162 1 ALL alerts. 
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Step6 Click the Add button. 
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Figure 6-13 IntruShield Target SNMP Server 
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Step7 = On the SNMP Forwarder page, enter: 
Enable SNMP Forwarder: Select the Yes radio button. 
b. Target Server (IP Address): Enter MARS’s IP address as it appears to IntruShield. 
c. Target Server Port Number: Enter MARS’s port number 162. 
d. SNMP Version: | 
e. Forward Alerts 
f. Select the severity from the list. Cisco recommends selecting Informational and above severity. 
g. Customize Community: Enter the community string that you want to use. 


Step8 Click Apply and exit the program. 


Add and Configure an IntruShield Manager and its Sensors in MARS 


Adding an IntruVert device has two distinct steps. First, you add configuration information for the for 
the IntruShield Manager host. Second, you add the sensors managed by that host. 


e Add the IntruShield Manager Host to MARS, page 6-26 
e Add IntruShield Sensors Manually, page 6-26 
e Add IntruShield Sensors Using a Seed File, page 6-27 
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Add the IntruShield Manager Host to MARS 


Step 1 
Step 2 


Step 3 
Step 4 
Step 5 
Step 6 
Step7 


Step 8 


To define the host and represent the management console for IntruShield, follow these steps: 


Click Admin > System Setup > Security and Monitor Devices > Add. 


From the Device Type list, select Add SW Security apps on a new host or Add SW security apps on 
existing host. 


Enter the Device Name and IP addresses if adding a new host. 
Click Apply. 

Click Reporting Applications tab. 

Select IntruVert IntruShield 1.5 from the Select Application list. 


To complete the definition of this console, click Add. 


Figure 6-14 Add IntruShield Sensors 


Management Console 


Add or edit sensors for this intruvert management console. 


Add Sensor Edit Sensor Remove Sensor Load From CSV 
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Continue defining the sensors that the console manages using one of two methods: 
e Add IntruShield Sensors Manually, page 6-26 
e Add IntruShield Sensors Using a Seed File, page 6-27 


Add IntruShield Sensors Manually 


Step 1 
Step 2 


Step 3 
Step 4 


To add sensors manually, follow these steps: 


Click Add Sensor. 
Enter the Device Name, Sensor Name, and its Reporting IP address. 

e¢ Device Name — the DNS entry for this device 

e Sensor Name -— the name as it appears in the console 

e Reporting IP — the IP address that the agent uses to send logs to the console 
Add the interface information. 


For attack path calculation and mitigation, specify the networks being monitored by the sensor. Do one 
of the following: 


To manually define the networks, select the Define a Network radio button. 


a. Enter the network address in the Network IP field. 
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b. Enter the corresponding network mask value in the Mask field. 

c. Click Add to move the specified network into the Monitored Networks field. 

d. Repeat as needed. 

To select the networks that are attached to the device, click the Select a Network radio button. 
a. Select a network from in the Select a Network list. 

b. Click Add to move the selected network into the Monitored Networks field. 

c. Repeat as needed. 

To save your changes, click Submit. 


To enable MARS to start sessionizing events from this module, click Activate. 


Add IntruShield Sensors Using a Seed File 


Step 1 


Step 2 


Step 3 


Step 4 


Step 5 


Step 6 
Step7 
Step 8 


To add sensors using a seed file, follow these steps: 


Click Load From CSV. 
Enter the FTP server information and location of the CSV (comma separated values) file. 


e If you need to generate the IntruShield sensors CSV file, Extracting Intruvert Sensor Information 
from the IntruShield Manager, page 6-22. 


Click Submit. 
The list of sensors appears on the management console page. 


For each sensor that appears in the management console page, select the check box next to the sensor 
and click Edit Sensor. 


For attack path calculation and mitigation, specify the networks being monitored by the sensor. Do one 
of the following: 


To manually define the networks, select the Define a Network radio button. 

a. Enter the network address in the Network IP field. 

b. Enter the corresponding network mask value in the Mask field. 

c. Click Add to move the specified network into the Monitored Networks field. 

d. Repeat as needed. 

To select the networks that are attached to the device, click the Select a Network radio button. 
a. Select a network from in the Select a Network list. 

b. Click Add to move the selected network into the Monitored Networks field. 

c. Repeat as needed. 

To save your changes, click Submit. 

To save the changes made to this management console and the sensors it manages, click Submit. 


To enable MARS to start sessionizing events from this module, click Activate. 
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Snort 2.0 


Configure Snort to Send Syslogs to MARS 


Step 1 


Step 2 


Step 3 


For Snort, use the syslog as your output plugin. Configure your syslogd to send copies to another host. 
On most older-style systems (Solaris/Linux), you need to edit /etc/syslog.conf. (Assuming that 
the system is based on syslogd, and not any of the newer system logging facilities. The newer logging 
facilities are not supported by Snort.) 


To configure Snort to send syslog messages to the MARS Appliance, follow these steps: 


Make Snort’s output go to syslog with log facility local4 in snort.conf (you can pick any local 
facility that's unused.) 


output alert_syslog: LOG_LOCAL4 LOG_ALERT 
snort.conf is normally in /etc/snort. 


Add a redirector in your /etc/syslog.conf on your Snort box to send syslog to MARS. 


local4.alert @IPAddrOffMarsbox 


Restart the Snort daemon and the syslogd daemon on your Snort box. 


Add the Snort Device to MARS 


Step 1 
Step 2 


Step 3 
Step 4 
Step 5 
Step 6 
Step7 
Step 8 


To add the Snort device to MARS, follow these steps: 


Click Admin > System Setup > Security and Monitor Devices > Add 


From the Device Type list, select Add SW Security apps on a new host or Add SW security apps on 
existing host 


Enter the Device Name and IP addresses if adding a new host. 
Click Apply 

Click Reporting Applications tab 

From the Select Application list, select Snort Snort 2.0 

Click Add 


For attack path calculation and mitigation, specify the networks being monitored by the sensor. Do one 
of the following: 


To manually define the networks, select the Define a Network radio button. 

a. Enter the network address in the Network IP field. 

b. Enter the corresponding network mask value in the Mask field. 

c. Click Add to move the specified network into the Monitored Networks field. 
d. Repeat as needed. 
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Symantec ManHunt Wl 


To select the networks that are attached to the device, click the Select a Network radio button. 
a. Select a network from in the Select a Network list. 
b. Click Add to move the selected network into the Monitored Networks field. 
c. Repeat as needed. 
Step9 To save your changes, click Submit. 


Step10 To enable MARS to start sessionizing events from this module, click Activate. 


Symantec ManHunt 


Symantec ManHunt Side Configuration 


Step1 Login to the Symantec ManHunt with appropriate username and password. 


Step2 In the main screen, click Setup > Policy > Response Rules, then Response Rules window will appear. 


Figure 6-15 ManHunt Configuration 
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Step3 In the Response Rules window, click Action > Add response Rules. 


Step4 Click in the field of Response Action 
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Step 5 


Step 6 


Figure 6-16 ManHunt Response Rule Config 
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In the left menu, click SNMP Notification and enter the following information: 


a. SNMP Manager IP address: Reporting IP address of MARS 


b. Maximum number of SNMP notification: (Example: 100000). 


c. Delay between SNMP notification (mins): (Example: | min) 


Click OK to return to main screen. 


MARS Side Configuration 


Add Configuration Information for Symantec ManHunt 3.x 


Step 1 
Step 2 


Step 3 
Step 4 
Step 5 


Click Admin > System Setup > Security and Monitor Devices > Add 


From the Device Type list, select Add SW Security apps on a new host or Add SW security apps on 


existing host 


Enter the Device Name and IP addresses if adding a new host. 


Click Apply 


Click Reporting Applications tab 
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Step 6 
Step 7 
Step 8 


Step 9 
Step 10 


NetScreen IDP2.1 Hl 


From the Select Application list, select Symantec ManHunt 3.x 
Click Add 


For attack path calculation and mitigation, specify the networks being monitored by the sensor. Do one 
of the following: 


To manually define the networks, select the Define a Network radio button. 

a. Enter the network address in the Network IP field. 

b. Enter the corresponding network mask value in the Mask field. 

c. Click Add to move the specified network into the Monitored Networks field. 

d. Repeat as needed. 

To select the networks that are attached to the device, click the Select a Network radio button. 
a. Select a network from in the Select a Network list. 

b. Click Add to move the selected network into the Monitored Networks field. 

c. Repeat as needed. 

To save your changes, click Submit. 


To enable MARS to start sessionizing events from this module, click Activate. 


NetScreen IDP 2.1 


IDP-side Configuration 


Step 1 
Step 2 
Step 3 
Step 4 


Step 5 
Step 6 
Step 7 
Step 8 


Click NetScreen-Global Pro > IDP Manager > IDP. 
Log in to the IDP Manager. 
From the main menu, click Tools > Preferences. 


In the tree on the left, click Management Server, enter the Local Controller’s address in the Syslog host 
field, and click OK. 


Click Security Policies, and the name of your policy. 
In the Notification column, right-click anywhere in the cell in the field and select Configure. 
Check enable logging and syslog for each policy, and click OK. Repeat for all of your policies. 


From the main menu, click Policy > Install. 


MARS-side Configuration 


Add Configuration Information for the IDP 


Step 1 


Click Admin > System Setup > Security and Monitor Devices > Add. 
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Step 2 


Step 3 
Step 4 
Step 5 
Step 6 
Step7 


From the Device Type list, select Add SW Security apps on a new host or Add SW security apps on 
existing host. 


Enter the Device Name and IP Addresses if adding a new host. 
Click Apply. 

Click Reporting Applications tab. 

From the Select Application list, select NetScreen IDP 2.1. 
Click Add. 


Figure 6-17 Add NetScreen IDP 2.1 Sensors 


Management Console 


Add or edit sensors for this netscreen IDP management console. 


Add Sensor | Edit Sensor I Remove Sensor | | Load From CSV 
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Add NetScreen IDP 2.1 Sensors Manually 


Step 1 
Step 2 
Step 3 


Step 4 


Step 5 


Click Add Sensor. 
Select existing device or Add New device. 
Enter the Device Name, Sensor Name, and its Reporting IP address. 
e Device Name — the DNS entry for this device 
e Sensor Name -— the name as it appears in the console 
e¢ Reporting IP — the IP address that the agent uses to send logs to the console 
Add the interfaces, which important information for attack path calculation. 


e For multiple interfaces, click Add Interface, and add the new interfaces’s name, IP address and 
mask. 


For attack path calculation and mitigation, specify the networks being monitored by the sensor. Do one 
of the following: 


To manually define the networks, select the Define a Network radio button. 

a. Enter the network address in the Network IP field. 

b. Enter the corresponding network mask value in the Mask field. 

c. Click Add to move the specified network into the Monitored Networks field. 

d. Repeat as needed. 

To select the networks that are attached to the device, click the Select a Network radio button. 
a. Select a network from in the Select a Network list. 


b. Click Add to move the selected network into the Monitored Networks field. 
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Step 6 
Step 7 


Enterasys Dragon6.x Ml 


c. Repeat as needed. 
To save your changes, click Submit. 


To enable MARS to start sessionizing events from this module, click Activate. 


Enterasys Dragon 6.x 


To configure the Enterasys Dragon devices, you must: 
e Configure the Dragon Policy Manager (DPM) or Event Flow Processor (EFP). 
e Configure the syslog daemon running on the same system as the DPM or EFP. 


e Configure the MARS. 


DPM/EFP Configuration 


Before you configure the DPM or EFP, you must install and enable the Alarmtool. 


Configure the DPM or EFP 


Step 1 
Step 2 
Step 3 
Step 4 


Step 5 
Step 6 
Step 7 
Step 8 
Step 9 
Step 10 


Step 11 


Log into the DPM or EFP. 

Click Alarmtool. 

In the left menu, click Notification Rules. 

In the right window, select syslog if it exists. If not, you need to create it: 

a. Click New Notification Rules and select syslog. 

b. Facility - Make sure the localv you select is not in use by the syslog daemon 
c. Level - Select Debug 


d. Message - Make sure its in such format: 


STIMES SDATE% SigName=SNAME% from Sensor=%SENSOR% 
ScrIP=%SIP% DstIP=%DIP% SrcPort=%SPORT% DstPort=%DPORT% 
Protocol=%PROTO% 


Click Save. 

In the left menu, click Alarm. 

Set the Type to Real-time and the Notification Rule to syslog. 
Click Save. 

In the left menu, click Deployment. 


In the main screen, click View Configuration. Make sure the local set in both notify syslog and alarm 
syslog match. 


In the main screen, click Deploy and Reset to confirm the configuration change. 
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Host-side Configuration 


Configure the syslog on the UNIX host 


Step 1 Log into the host as the root user. 

Step2 On the same system running the DPM or EFP, edit the file /etc/syslog.conf. 
Step3. Make sure n in localn matches the syslog entry you used on the DPM or EFP. 
Step4 —_‘ Restart the syslog daemon by entering: 


/etc/init.d/syslog restart 


MARS-side Configuration 


Add Configuration Information for the Enterasys Dragon 


Step1 Click Admin > System Setup > Security and Monitor Devices > Add. 


Step2 From the Device Type list, select Add SW Security apps on a new host or Add SW security apps on 
existing host 


Step3 Enter the Device Name and IP Addresses if adding a new host. 
Step4 = Click Apply 

Step5 Click Reporting Applications tab 

Step6 From the Select Application list, select Enterasys Dragon 6.x 
Step7 Click Add. 


Add a Dragon NIDS Device 


Step 1 Click Add Sensor. 
Step2 Select existing device or Add New device. 
Step3 Enter the Device Name, Sensor Name, and its Reporting IP address. 
e Device Name — the DNS entry for this device 
e Sensor Name — the name as it appears in the console 
e¢ Reporting IP — the IP address that the agent uses to send logs to the console 
Step4 = Add the interfaces, which important information for attack path calculation. 


e For multiple interfaces, click Add Interface, and add the new interfaces’s name, IP address and 
mask. 


Step5 ~—“ For attack path calculation and mitigation, specify the networks being monitored by the sensor. Do one 
of the following: 
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To manually define the networks, select the Define a Network radio button. 
a. Enter the network address in the Network IP field. 
b. Enter the corresponding network mask value in the Mask field. 
c. Click Add to move the specified network into the Monitored Networks field. 
d. Repeat as needed. 
To select the networks that are attached to the device, click the Select a Network radio button. 
a. Select a network from in the Select a Network list. 
b. Click Add to move the selected network into the Monitored Networks field. 
c. Repeat as needed. 
Step6 To save your changes, click Submit. 
Step7 Click Done when you are done adding the sensor. 


Step8 To enable MARS to start sessionizing events from this module, click Activate. 
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Configuring Host-Based IDS and IPS Devices 


Host-based intrusion detection and prevention devices provide MARS with detailed information about 
attacks seen at the host level, rather than the network level. They also provide information about the host 
operating system and successful prevention of attacks, both of which provide more targeted data for false 
positive analysis. 


This chapter explains how to bootstrap and add the following host-based IDS and IPS devices to MARS: 
e Entercept Entercept 2.5 and 4.0, page 7-1 
e Cisco Security Agent 4.x Device, page 7-5 


Entercept Entercept 2.5 and 4.0 


To configure Entercept in MARS, you must perform the following tasks: 


1. Generate CSV file that identifies each of the Entercept hosts by logging into the host running the 
Entercept console and copying the data out of the database table. 


Configure the Entercept console to send SNMP traps to the MARS Appliance 
Identify the events that should be generated as SNMP traps. 


Define a host that represents the management console (Entercept console) in MARS web interface. 


oF YS Df 


From that host in the MARS web interface, import the CSV seed file to identify the Entercept agents 
running on other hosts. 


The following sections provide details on performing each of these tasks: 
e Extracting Entercept Agent Information into a CSV file (for Entercept Version 2.5), page 7-1 
e Define the MARS Appliance as an SNMP Trap Target, page 7-2 
e Specific the Events to Generate SNMP Traps for MARS, page 7-2 


Extracting Entercept Agent Information into a CSV file (for Entercept Version 
2.5) 


wy 


Note Entercept agent information is saved in a database file on the Entercept console. 
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When you configure the MARS box to add Entercept agents, you can extract them from the database file 
on the Entercept console, instead of typing the mapping for each agent. 


Create a CSV file for Entercept Agents in Version 2.5 


Step 1 Go to the directory Program Files\Cisco IDS\Console\Database and copy the file 
CoreShield.mdb to another directory, e.g.: C: \temp. 


Step2 Open the copied CoreShield.mdb with Microsoft Access, and go to the “Agents” table. 
Step3 Export the table to a file named: Agents.txt and choose the exported file format to be CSV. 


Step4 Copy Agents.txt toa specific directory that is ready for the MARS box to load. 


Asampleagents.txt file could be: 
1,3, "entercepti",6,1,1,1,438,1,"127.0.0.1",0,,1051055867, 2086 


where the fields are: AgentID, AgentTypeID, ComputerName, ComputerType, 
NewFlag, StatusID, OperatingModeID, VersionID, VersionModeID, IP, 
License, Note, NoConnection, and UpTime. 


Define the MARS Appliance as an SNMP Trap Target 


Step 1 Log in to the Entercept Console. 
Step2 Click Configuration. 
Step3 Click the Address Book tab. 
Step4 —_—In the All Contacts tree, click SNMP Trap. 
Step 5 Click the Plus (+) button. 
Step6 In the New SNMP Trap page: 
a. Enter an Alias for the MARS Appliance. 
b. Set Privilege Level to Global. 
c. Set Status to Enabled. 


d. Enter the MARS Appliance’s name if the DNS server can resolve the name. Otherwise, use its IP 
address. 


e. Enter a community string name in the Community field. 
f. Enter a Port number. 


g. Select a Protocol. 


Specific the Events to Generate SNMP Traps for MARS 


Step 1 Click the Notifications tab. 
Step 2 Click the Plus (+) button. 
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Step 3 
Step 4 
Step 5 


Step 6 


Step 7 


Step 8 


Entercept Entercept 2.5 and 4.0 Hi 


On the General tab, in the name field, enter a name for the notification. 
Click the Agent Groups tab and select the All Agents radio button. 


Click the Security Events tab and select the Events by Severity Levels radio button. Select the events 
that you want (High, Medium, Low, and Information). 


Click the System Events tab and select the Events by Severity Levels radio button. Select the events 
that you want (Error, Warning, and Information). 


Click the Address Book tab and click a destination in the Available Destinations field. Click the Down 
arrow to move it into the Selected Destinations field. 


Click OK and exit the program. 


Add and Configure an Entercept Console and its Agents in MARS 


Adding an Entercept device has two distinct steps. First, you add configuration information for the for 
the Entercept Console host. Second, you add the agents managed by that console. 


e Add and Configure an Entercept Console and its Agents in MARS, page 7-3 
e Add Entercept Agents Manually, page 7-4 
e Add Entercept Agents Using a Seed File, page 7-4 


Add the Entercept Console Host to MARS 


Step 1 
Step 2 


Step 3 
Step 4 
Step 5 
Step 6 
Step7 
Step 8 
Step 9 
Step 10 


Click Admin > Security and Monitor Devices > Add. 


From the Device Type list, select Add SW Security apps on a new host or Add SW security apps on 
existing host. 


Enter the Device Name and IP addresses if adding a new host. 

Click Apply. 

Click on Reporting Applications tab. 

From the Select Application list, select Entercept 2.5 or 4.0 

Click Add. 

Enter the Console Name. 

Check the “Is Sensor” check box—which is asking if it is a sensor or not. 


Enter the sensor’s Agent Name, which is the agent name for the console if it is an agent. 
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Step 11 


Management 
Console 


> *Console Name:/ | 


> yf IsSensor 


*Agent Name: 


143220 


| Cancel Submit 


Click Submit. 


You could now add the agents. 


Add Entercept Agents Manually 


Step 1 
Step 2 
Step 3 


Step 4 


Click Add Agent. 
Select the device that already has agent running or Add New. 
Enter the Device Name, Agent Name, and its Reporting IP address if 
Adding new device 
e For the first interface, enter an IP address and mask. 
e For multiple interfaces, click Add Interface, and add the new interfaces’ IP address and mask. 
Click Submit. 


Add Entercept Agents Using a Seed File 


Step 1 
Step 2 


Step 3 


Click Load From CSV. 
Enter the FTP server information and location of the CSV (comma separated values) file. 


e If you need to generate the Entercept Agent CSV file, see Extracting Entercept Agent Information 
into a CSV file (for Entercept Version 2.5), page 7-1. 


Click Submit. 
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Cisco Security Agent 4.x Device 


wy 


To enable Cisco Security Agent (CSA) as a reporting device in MARS, you must identify the CSA 
Management Console (CSA MC) as the reporting device. The CSA MC receives alerts from the CSA 
agents that it monitors, and it forwards those alerts to MARS as SNMP notifications. 


When MARS receives the SNMP notification, the source IP address in the notification is that of the CSA 
agent that originally triggered the event, rather than the CSA MC that forwarded it. Therefore, MARS 
requires host definitions for each of the CSA agents that can potentially trigger an event. These 
definitions are added as sub-components under the device definition of the CSA MC. 


As of MARS, release 4.1.1, the MARS Appliance discovers CSA agents as they generate alerts, 
eliminating the need to manually define them. MARS parses the alert to identify the CSA agent 
hostname and to discover the host operating system (OS). MARS uses this information to add any 
undefined agents as children of the CSA MC as a host with either the Generic Windows (all Windows) 
or Generic (Unix or Linux) operating system value. You are still required to define the CSA MC; 
however, you are not required to define each agent. The default topology presentation for discovered 
CSA agents is within a cloud. 


Note 


Note 


The first SNMP notification from an unknown CSA agent appears to originate from the CSA MC. MARS 
parses this notification and defines a child agent of the CSA MC using the discovered settings. Once the 
agent is defined, all subsequent messages appear to originate from the CSA agent. 


Prior to 4.1.1., you were required to manually add each agent or by using an exported hosts file, as 
defined in Export CSA Agent Information to File, page 7-6. 


Prior to the 4.1.1 release, CSA was identified by the device type name Cisco CSA 4.0. As part of an 
upgrade, any Cisco CSA 4.0 devices were renamed as Cisco CSA 4.x. This new name includes support 
for Cisco CSA 4.0 and 4.5. 


This section contains the following topics: 
e Configure CSA Management Center to Generate Required Data, page 7-5 
e Add and Configure a CSA MC Device in MARS, page 7-7 
e Troubleshooting CSA Agent Installs, page 7-10 


Configure CSA Management Center to Generate Required Data 


To bootstrap CSA, you must configure the CSA MC to forward SNMP notifications to the MARS 
Appliance. In addition, you can export the list of CSA agents in a format that MARS can import. 
However, this export operation is not necessary, as MARS discovers the agents as they generate 
notifications. 


This section contains the following topics: 
e Configure CSA MC to Forward SNMP Notifications to MARS, page 7-6 
e Export CSA Agent Information to File, page 7-6 
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Configure CSA MC to Forward SNMP Notifications to MARS 


Step 1 
Step 2 


Step 3 
Step 4 
Step 5 
Step 6 
Step7 
Step 8 
Step 9 


The only required configuration is to ensure that CSA MC forwards the SNMP notifications that it 
receives from agents to MARS. From these notifications, MARS is able to discover the agent and its 
relevant settings. It is also from these events that MARS learns about the host-level activities transpiring 
on your network.\ 


To forward all notifications to the MARS Appliance, follow these steps: 


Log in to the CiscoWorks Server desktop. 


From the navigation tree, select VPN/Security Management Solution >Management Center > 
Security Agents. 


In the Management Center screen, click the Alerts link. 

Click New. 

In the Name and Description fields, enter a name and description for the SNMP notification. 
Scroll down and select the SNMP check box. 

In the Community name field, enter the SNMP notification’s community name. 

In the Manager IP address field, enter the MARS’s IP address. 


Click Save and exit the program. 


Export CSA Agent Information to File 


S 


With the release of MARS 4.1.1, you are no longer required to define each Cisco CSA agent, as they are 
discovered as a device sends an SNMP notification to the CSA Management Console (CSA MC). 


Note 


Step 1 


Step 2 
Step 3 
Step 4 
Step 5 


Step 6 
Step 7 
Step 8 
Step 9 


The following instructions apply to Cisco CSA 4.x when Microsoft Internet Explorer is used to access 
the CSA MC web interface. 


To export the all hosts report as a tab-delimited file, follow these steps: 


Log in to the CSA MC by accessing the console using the fully qualified domain name in the URL. 


When accessing the CSA MC, you must use a fully qualified domain name in the URL. If you use the 
CiscoWorks Desktop to launch CSA MC, the ActiveX reports do not display. 


Click Reports > Host Details. 

Click New. 

In Groups, choose <All Hosts>, in Viewer Type, choose ActiveX (IE only). 

Click View report. 

A window appears that contains the host details. 

Click Export, and select export to an Excel 5.0 Document type. 

In the Name box, identifies the name for the file that you are exporting, for example, csahosts.xls. 
Open the exported file in Excel, and click File > Save As... 

In the Save as type box, click Text (Tab delimited) (*.txt). 
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Step 11 


Cisco Security Agent 4.x Device Mil 


In the File name box, enter the name for this file, for example, csahosts.txt, and click Save. 
Upload the generated file to an FTP server where the MARS Appliance can access it. 


You will return to this file when adding the CSA device n the MARS web interface, as defined in Add 
and Configure a CSA MC Device in MARS, page 7-7. 


Add and Configure a CSA MC Device in MARS 


Step 1 
Step 2 


Step 3 
Step 4 
Step 5 
Step 6 
Step 7 
Step 8 


Step 9 
Step 10 


Before you can identify the agents, you must add the CSA MC to MARS. All CSA agents forward 
notifications to the CSA MC, and the CSA MC forwards SNMP notifications to MARS. Once you define 
the CSA MC and activate the device. MARS can discover the agents that are managed by that CSA MC. 
However, you can also chose to manually add the agents. 


To add a CSA MC to MARS, follow these steps: 


Click Admin > Security and Monitor Devices > Add. 


From the Device Type list, select Add SW security apps on a new host or Add SW security apps on 
existing host. 


Enter the Device Name and IP addresses if adding a new host. 
Click Apply. 

Click Reporting Applications tab. 

From the Select Application list, select Cisco CSA 4.x. 

Click Add. 


The Management Console page appears. 


Management Console 


4dd or edit agents for this csa management console. 


Add Agent Edit Agent Delete Agent Load From File 


143194 


Cancel Submit 


Click Submit, and then click Done. 
Do one of the following: 


e To save your changes and allow the CSA agents to be discovered automatically, click Submit, and 
then click Done. 


e To add agents using an exported hosts report, continue with Add CSA Agents From File, page 7-9. 
e To add a single agent manually, continue with Add a CSA Agent Manually, page 7-8 
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Add a CSA Agent Manually 


You can manually add a CSA Agent as a child of the CSA MC. This feature allows you to represent all 


of your agents, even if they have not generated any notifications. 


To add CSA agents manually, follow these steps: 


Step1 Click Admin > Security and Monitoring Devices. 
Step2 From the list of devices, select the host running Cisco CSA Management Center, and click Edit. 
Step3 Click the Reporting Applications tab, select Cisco CSA Management Center in the Device Type list, 
and click Edit. 
Step4 Click the Add Agent. 
Step5 Do one of the following: 
e Select the existing device, click Edit Existing, and continue with Step 8. 
A page displays with the values pre-populated for hostname, reporting IP address, and at least one 
interface. 
e Click Add New, and continue with Step 6. 
+ ACSA agent will be added to this device. 
> *Device Name: | ] 
> Reporting IP: | || l{ |] ] 
[_Addinterface | [ Remove interface | 
Name: IP Address: Network Mask: 
T [ethero a | | | | | | 
Cancel Submit & 
Step6 In the Device Name field, enter the hostname on which this CSA agent resides. 
This value should reflect the DNS entry for this device. 
Step7 —_—_In the Reporting IP field, enter the IP address that the agent uses to send logs to the CSA MC. 
Step8 Define each interface that is configured for this host by specifying the interface name, IP address, and 
network mask. To add a new interface, click Add Interface. 
The interface settings are used for attack path calculation. It is very important that you identify any 
dual-homed hosts by defining each interface. 
Step9 Click Submit, and then click Done. 
Step10 To activate this device, click Activate. 
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Add CSA Agents From File 


Step 1 
Step 2 
Step 3 


Step 4 


A 


You can add the complete list of hosts on which CSA Agents are installed by exporting the all hosts 
report from CSA MC and importing that file into MARS. The only advantage to adding agents using an 
export file is that the first notification received that originates from the agent is not attributed to the 
CSA MC. 


To add CSA agents from a file, follow these steps: 


Click Admin > Security and Monitoring Devices. 
From the list of devices, select the host running Cisco CSA Management Center, and click Edit. 


Click the Reporting Applications tab, select Cisco CSA Management Center in the Device Type list, 
and click Edit. 


Click Load From File. 


Remote File Location: 


> *IP Address: i i me 


> *User Name: } 


> *Password: 
> *Path: 


> *File Name: ] 


143193 


Caution The file should be formatted as a tab delimited file. You cannot use a CSV file. To generate a tab 

delimited file of the CSA agents managed by the CSA MC, see Export CSA Agent Information to File, 
page 7-6. 

Step5 —=In the IP Address field, enter the address of the FTP server where you stored the exported hosts file, as 
described in Export CSA Agent Information to File, page 7-6. 

Step6 Inthe User Name field, enter the name of the account used to authenticate to the FTP server. 

Step7 ‘In the Password field, enter the password that corresponds to the account specified in Step 6. 

Step 8 In the Path field, enter the path to the folder where the file is stored. If this file is stored in the root folder, 
you must specify a backslash (\) in this field. The format of this value is \<path_here>\. 

Step9 In the File Name field, enter the name of the tab delimited file. 

Step10 Click Submit. 
The following message displays and the hosts are added as agents of the CSA MC: 
Success: 
Status: OK 

Step11. Click Done. 
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Troubleshooting CSA Agent Installs 


When importing CSA agents from a file, the following messages can occur. 


Table 7-1 Error and Status Messages when Importing CSA Agents from File 

Message Description/Issue 

Status: NumberFormatException occurred Occurs when you have a CSV file rather than a tab 
parsing the file at line X delimited file. The line number varies. 

Error Occurred: Occurs when duplicate files are imported, even if 
Status: DbDevice occurred parsing the file at line you have deleted all of the agents and the 

-| CSA MC. 

Success: Indicates a successful import of CSA agents using 
Status: OK the tab-delimited file. 

Error Occurred: Indicates that the file does not exist at the 


specified path. If the path is at the root of your 
FTP server, verify that you have included \ as the 
path value. 


Status: FileNotFoundException 


Error Occurred: Indicates that the identified FTP server is not 
reachable from the MARS Appliance. You may 
need to define additional routes or enable traffic 
flows to ensure the connection is allowed. 


Status: NoRouteToHostException 
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Configuring Antivirus Devices 


Antivirus (AV) devices provide detection and prevention against known viruses and anomalies. 
This chapter describes how to configure and add the following devices and systems: 

e Symantec AntiVirus Configuration, page 8-1 

e McAfee ePolicy Orchestrator Devices, page 8-8 


e Cisco Incident Control Server, page 8-13 


Symantec AntiVirus Configuration 


Configuring the Symantec AV requires performing two tasks: 
e Configure the AV Server to Publish Events to MARS Appliance, page 8-1 
e Add the Device to MARS, page 8-7 

In addition, you can perform the following task to expedite populating the Agent list in MARS: 
e Export the AntiVirus Agent List, page 8-7 


Configure the AV Server to Publish Events to MARS Appliance 


To configure the AV server to publish events to MARS, follow these steps: 


Step 1 Log in to the Windows server running Symantec AV. 


Step2 To identify the Local Controller as a valid SNMP trap destination, click Administrative Tools > 
Services > SNMP Service > Traps > Trap destinations. 


Step3 —_ Enter the IP address of the Local Controller in the Trap Destination page, and click OK to close all open 
windows. 


Step4 Select Start > All Programs > Symantec System Center Console. 
Step5 Inthe Symantec System Center window, click System Hierarchy. 


Step6 | Under System Hierarchy, right-click the appropriate server group name and unlock the server group by 
supplying the configured password. 


Unlocking the server enables you to configure it. 
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Figure 8-1 
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Step7 Configure Symantec server (AMS-Alert Management System) to send SNMP traps to MARS. Right 
click the unlocked server group name, then select All Tasks > AMS > Configure. 


Figure 8-2 
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Step8 Select Send SNMP Trap under each Alert Action, then click Configure. 
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Symantec AntiVirus Configuration 


Figure 8-3 Symantec AV Trap 
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Step9 Click Send SNMP trap, and then click Next. 


Figure 8-4 Symantec AV Send SNMP Trap 
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Step10 Select the Local Controller to send the SNMP trap to as defined in Step 3, and then click Next to view 
the Action Message window. 


Step11_ Add alert parameters to the Alert message list according to the following information: 
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Figure 8-5 Symantec AV Action Msg 
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The following mandatary fields are required for MARS to parse AV traps. If these fields are among those 
possible, you must define these fields in order before defining any of the optional fields. 


e Alert: <Alert Name> 

¢ Computer: <Computer Name> 
e Date: <Date> 

e Time: <Time> 

e Action: <Actual Action> 

e Description: <Description> 


wy 


Note This ordering is required is because some optional fields can be so long as to prevent Mars from correctly 
parsing the mandatory fields if they do not appear first in the list of attributes. 


The following optional fields can be defined after all mandatory fields are defined: 
e User: <User> 
e Virus Name: < Virus Name> 
e File Path: <File Path> 
e Severity: <Severity> 
e Source: <Source> 
The following list identifies the trap type and the full list of possible fields: 
Alert: Virus Found 
e Alert: <Alert Name> 
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Computer: <Computer Name> 

Date: <Date> 

Time: <Time> 

Action: <Actual Action> 

Severity: <Severity> 

Source: <Source> 

File Path: <File Path> 

Logger: <Logger> 

Requested Action: < Requested Action> 
User: <User> 


Virus Name: <Virus Name> 


Alert: Virus Definition File Update 


Alert: <Alert Name> 
Computer: <Computer Name> 
Date: <Date> 

Time: <Time> 

Description: <Description> 
Severity: <Severity> 


Source: <Source> 


Symantec AntiVirus Configuration 


Alert: Symantec AntiVirus Startup/Shutdown 


Alert: <Alert Name> 
Computer: <Computer Name> 
Date: <Date> 

Time: <Time> 

Description: <Description> 
Severity: <Severity> 


Source: <Source> 


Alert: Scan Start/Stop 


Alert: <Alert Name> 
Computer: <Computer Name> 
Date: <Date> 

Time: <Time> 

Severity: <Severity> 

Source: <Source> 

Source: <Source> 

Logger: <Logger> 


User: <User> 


Alert: Scan Start/Stop 
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Alert: <Alert Name> 
Computer: <Computer Name> 
Date: <Date> 

Time: <Time> 

Description: <Description> 
Severity: <Severity> 

Source: <Source> 


Logger: <Logger> 


Alert: Default Alert 


Alert: <Alert Name> 
Computer: <Computer Name> 
Date: <Date> 

Time: <Time> 

Severity: <Severity> 

Source: <Source> 


Failed Alert: <Failed Alert> 


Alert: Configuration Change 


Alert: <Alert Name> 
Computer: <Computer Name> 
Date: <Date> 

Time: <Time> 

Severity: <Severity> 

Source: <Source> 


Failed Alert: <Failed Alert> 


Alert: Configuration Change 


Alert: <Alert Name> 
Computer: <Computer Name> 
Date: <Date> 

Time: <Time> 

Description: <Description> 
Severity: <Severity> 


Source: <Source> 


Step12 Repeat Step 8 through Step 11 for each alert event. 
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Export the AntiVirus Agent List 


You can export the list of Symantec AntiVirus Clients and Agents as a CSV file (*.csv), which enables 
you to use the CSV file to load the agents into MARS. For more information on adding agents from the 
file, Add Agents from a CSV File, page 8-8. This approach is much faster than if you had to identify the 
agents manually. 


To generate the CSV file, follow these steps: 


Step 1 Select = View > Default Console View to ensure the generated CVS file will be based on the Console 
Default View. 


Step2 _—_- Right-click the name of the server that you want to export, choose Export List, and save it as Text 
(Comma Delimited) (*.csv) file. 


Step3 = Copy the file to an FTP server that the MARS Appliance can access. 


You will use this file when you add the AntiVirus agents within the web interface. 


Add the Device to MARS 


Adding a device to MARS has two distinct steps. First, add the host configuration information . Then, 
add its agents, either manually or from the seed file. 


je 


Tip For Symantec AntiVirus, the Symantec agent hostname (AV client computer name) appears in the 
"Reported User" column of the event data. Therefore, you can define a query, report or rule related to 
this agent based on the "Reported User" value. 


To add the host and application configuration information, follow these steps: 


Step 1 Select Admin > Security and Monitor Devices > Add. 


Step2 Select Add SW Security apps on a new host or Add SW security apps on existing host from the 
Device Type list. 


Step3 To add anew host, enter the device name and IP addresses. 

Step4 = Click Apply. 

Step5 Click the Reporting Applications tab. 

Step6 From the Select Application list, select Symantec AntiVirus 9.x. 

Step7 Click Add, then add the agents. Continue with Add Agent Manually, page 8-7. 


Add Agent Manually 


To add an agent manually, follow these steps: 


Step1 Click Add Agent. 
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Step2 Select the existing device or click Add New. 
Step3 = Enter the following information for new device. 
* Device Name—The DNS entry for this device. 
* Reporting [P—The IP address that the agent uses to send logs to the console. 


Step4 Under the Interfaces list, specify the IP address and netmask values asscoaited with each interface 
installed in the host on which the agent is running. 


MARS uses interface information to calculate attack paths. 


Step5 Click Submit. 


Add Agents from a CSV File 


You can generate a CSV file that contains the list of agents managed by the Symantec AV server. Once 
the file is generated, you can use the file to import the list of agents into the MARS web interface as child 
modules of the Symantec AV server. 


To import the list of AV agents into MARS. follow these steps: 


Step 1 Click Load From CSV. 
Step 2 Enter the FTP server information and location of the CSV (comma-separated values) file. 


Step3 Click Submit. 


McAfee ePolicy Orchestrator Devices 


Configuring MARS to receive and process the data generated by a McAfee ePolicy Orchestrator server 
requires you to perform two procedures: 


e Configure ePolicy Orchestrator to Generate Required Data, page 8-8 
e Add and Configure ePolicy Orchestrator Server in MARS, page 8-12 


Configure ePolicy Orchestrator to Generate Required Data 


To prepare the ePolicy Orchestrator server to forward SNMP events to MARS, follow these steps: 


Step 1 Select Start > Program Files > Network Associates > ePolicy Orchestrator 3.x Console. 


Step2 _In the tree, select McAfee Security > ePolicy Orchestrator, and click the Log on to server link under 
Global Task List. 
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McAfee ePolicy Orchestrator Devices [i 


McAfee Security 
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Log On to Server 


Connect to the ePolicy Orchestrator Server 


@ Server name: | MCAFEE3 : 


User name: | admin 


Step3 In the Log On to Server dialog box, enter the username and password required to access the ePolicy 
Orchestrator server, and click OK. 


Step4 In the tree, select McAfee Security > ePolicy Orchestrator > <Server_Name> > Notifications and 
click the Configuration tab and click the SNMP Servers link. 


Step5 Click Add. 


“# ePolicy Orchestrator 3.5 


| action view || = > | @i\em| 2 
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Step6 Inthe Name field, enter the hostname of the MARS Appliance. 


Step7 In the Server address field, enter the IP address of the ethO interface, the monitoring interface for the 
MARS Appliance, and click OK. 


The SNMP server is added to represent the MARS Appliance. 
Step8 Click the Rules tab. 
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You can access the Rules tab by selecting McAfee Security > ePolicy Orchestrator > 
<Server_Name> > Notifications > and then clicking the Rules tab. 
Step9 Edit each rule in the list so that all notifications are sent to the SNMP server that represents the MARS 
Appliance. To edit a rule, follow these steps: 


a. Click the rule. 


The Describe Rule wizard page appears. 
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b. Click Next to proceed to Set Filters page. 
c. Under Add or Edit Notification Rule, click the 3. Set Thresholds link. 
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Figure 8-6 Set Threshold Values 
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d. Verify the Aggregation and Throttling values are set as shown in Figure 8-6 on page 8-11. 
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e. Click Next to proceed to the Create Notifications page. 
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f. Click Add SNMP Trap. 
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Figure 8-7 SNMP Trap Settings 
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g. Inthe SNMP server list, select the SNMP server that represents the MARS Appliance. 
h. Verify that all the variables are selected as shown in Figure 8-7 on page 8-12. 

i. Click Save to add the SNMP trap to the list of notifications for the selected rule. 

j. Click Finish to save the changes to the selected rule. 


k. Repeat Steps a. through j. for each rule. 


Add and Configure ePolicy Orchestrator Server in MARS 


Before MARS can begin processing SNMP traps from ePolicy Orchestrator, you must define the ePolicy 
Orchestrator server as software running on a host. When ePolicy Orchestrator is defined as a reporting 
device, MARS can process any inspection rules that you have defined using ePolicy Orchestrator event 
types. 


After you add the ePolicy Orchestrator server to MARS, the appliance can discover the agents that are 
managed by the ePolicy Ochestrator server as events are generated by those agents. You do not need to 
manually define the agents associated with this server. 


To add an ePolicy Orchestrator server to MARS, follow these steps: 


Step1 Select Admin > Security and Monitor Devices > Add. 
Step2 From the Device Type list, select Add SW Security apps on a new host. 
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Step 3 
Step 4 


Step 5 


Step 6 
Step7 
Step 8 


Step 9 


Step 10 
Step 11 


Cisco Incident Control Server Wl 


In the Device Name field, enter the hostname of the server. 


In the Reporting IP field, enter the IP address of the interface in the ePolicy Orchestrator server from 
which SNMP traps will originate. 


Under Enter interface information, enter the interface name, IP address, and netmask value of the 
interface in the ePolicy Orchestrator server from which syslog messages will originate. 


This address is the same value as the Reporting IP address. 

Click Apply. 

Click Next to move to the Reporting Applications tab. 

In the Select Application field, select McAfee ePO 3.5, and then click Add. 


Management Console 


Add or edit agents for this McAfee epo server. 


Add Agent Edit Agent Delete Agent 


284 


Cancel Submit |F 


Click Done to save the changes. 
Click Submit. 


To activate the device, click Activate. 


Cisco Incident Control Server 


The Cisco Incident Control Server (Cisco ICS) enables extended protection across Cisco IOS routers, 
switches, and IPS devices. In coordination with Trend Micro’s incident control solutions, Cisco ICS 
prevents the spread of day-zero outbreaks in three ways: 


e First, Cisco ICS issues temporary ACLs to those Cisco mitigation devices that can block such 
traffic, typically using a protocol and port pair block. This temporary block is referred to as an 
Outbreak Prevention ACL (OPACL). 


e Second, as soon as a signature is available, Cisco ICS updates all Cisco IPS and IDS devices running 
on your network with the signature required to detect and prevent the specific threat. This signature 
is referred to as an Outbreak Prevention Signature (OPSig). 


e Third, Cisco ICS can manage supporting products (sold seperately), such as Tend Micros’s Damage 
Cleanup Services (DCS), which cleans infected hosts by removing trojans and other malware. 


To complete the Cisco ICS communication settings, you must perform two tasks: configure Cisco ICS 
to send syslog messages to the MARS Appliance, and add the Cisco ICS management server to the 
MARS web interface as a reporting device. 


This section contains the following topics: 


e Configure Cisco ICS to Send Syslogs to MARS, page 8-14 
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e Add the Cisco ICS Device to MARS, page 8-15 
e Define Rules and Reports for Cisco ICS Events, page 8-15 


Configure Cisco ICS to Send Syslogs to MARS 


Step 1 
Step 2 


Step 3 


Step 4 


Step 5 


Cisco ICS publishes syslog messages to MARS. To configure Cisco ICS, you simply define a syslog 
server with the IP address of the MARS Appliance. You do not need to enable any special logs, and you 
cannot tune the messages that are sent to MARS. The Cisco ICS events for which syslog messages are 
geneerated have been selected to provide the most benefit to your Security Threat Mitigation (STM) 
system. 


To prepare Cisco ICS to publish events to MARS, follow these steps: 


Log in to the Cisco ICS Management Console. 
Click Global Settings > Syslog Servers. 


ro Cisco Incident Control Server 


Outbreak Management Devices Logs Updates Global Settings 


Add, delete, and configure Syslog servers, 


Gitadd jj Delete 


[" Server IP Address UDP Port 


143190 


Click Add. 


ror Cisco Incident Control Server 


Outbreak Management Devices Logs Updates Global Settings 


Syslog Servers > Added Syslog Server 


| Syslog Server Details 


rPAddess:[ 
UDP Port: [51a 


Save | Cancel | 
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In the IP Address field, enter the address of the MARS Appliance to which the Cisco ICS will publish 
syslog messages. 


Click Save. 


Cisco ICS now publishes syslog message to MARS. For MARS to be aware of this device, you must add 
the Cisco ICS device as a software application running on a host and you must click Activate in the web 
interface. 
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Add the Cisco ICS Device to MARS 


Step 1 
Step 2 


Step 3 
Step 4 


Step 5 


Step 6 
Step 7 
Step 8 


Step 9 
Step 10 
Step 11 


Before MARS can being processing the syslog messages as Cisco ICS messages, you must define the 
Cisco ICS management server as an software application running on a host. After Cisco ICS is defined 
as a reporting device, MARS can process any inspection rules that you have defined using Cisco ICS 
event types. 


To add a Cisco ICS server to MARS, follow these steps: 


Click Admin > Security and Monitor Devices > Add. 
From the Device Type list, select Add SW Security apps on a new host. 


You can also select Add SW Security apps on an existing host if you have already defined the host within 
MARS, perhaps as part of the Management >IP Management settings or if you are running another 
application on the host, such as Microsoft Internet Information Services. 


In the Device Name field, enter the hostname of the server. 


In the Reporting IP field, enter the IP address of the interface in Cisco ICS server from which the syslog 
messages will originate. 


Under Enter interface information, enter the interface name, IP address, and netmask value of the 
interface in Cisco ICS server from which the syslog messages will originate. 


This address is the same value as the Reporting IP address. 

Click Apply. 

Click Next to move the Reporting Applications tab. 

In the Select Application field, select Cisco ICS 1.x, then click Add. 


Cisco ICS 


Submit if you want to add Cisco ICS to this host 


Cancel Submit 
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Click Select to add the Cisco ICS application to this host. 
Click Done to save the changes. 


To activate the device, click Activate. 


Define Rules and Reports for Cisco ICS Events 


From Cisco ICS, MARS receives syslog messages that allow it to identify outbreaks, successful OPACL 
and OPSig deployments, and failed attempts to deploy. MARS stays abreast of when the OPACLs and 
OPSigs fire on Cisco IPS devices. MARS also monitors the Cisco ICS server for system issues, such as 
database failures. 


These events assist MARS in providing an accurate, holistic assessment of your network. OPACL and 
OPSig matching events provide five-tuple correlation, which MARS uses to perform attack path analysis 
and verify the containment of threats. You can uses the events to define inspection rules that help you 

perform manual mitigation on devices that cannot use OPACLs and OPSigs. 
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For example, an inspection rule could be written to match the OPACL event. Your mitigation team can 
respond by investigating the OPACL that was pushed to the reporting device, from which they can 
determine the five tuple (source address and port, destination address and port and network service). 
Using that information, they could push equivalent ACLs to devices not managed by Cisco ICS. 


When defining inspection rules or reports, you can access the list of Cisco ICS-specific events by 
entering Cisco ICS in the Description / CVE: field and clicking Search on the Management > Event 
Management page of the web interface. 


There are four predefined system inspection rules for Cisco ICS: 
¢ New Malware Discovered 
e New Malware Prevention Deployed 
e New Malware Prevention Deployment Failed 
e New Malware Traffic Match 
In addition, there are five predefined reports: 
e Activity: New Malware Discovered - All Events 
e Activity: New Malware Prevention Deployment Failure - All Events 
e Activity: New Malware Prevention Deployment Success - All Events 


e Activity: New Malware Traffic Match - All Events 


e Activity: New Malware Traffic Match - Top Sources 
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Configuring Vulnerability Assessment Devices 


Vulnerability assessment (VA) devices provide MARS with valuable information about many of the 
possible targets of attacks and threats. They provide information useful for accurately assessing false 
positives. This information includes the operating system (OS) running on a host, the patch level of the 
OS, the type of applications running on the host, as well as detailed logs about the activities occurring 


on that host. 
This chapter explains how to bootstrap and add the following VA devices to MARS: 


e Foundstone FoundScan 3.0, page 9-1 
e eEye REM 1.0, page 9-3 
¢ Qualys QualysGuard Devices, page 9-5 


Foundstone FoundScan 3.0 


To configure MARS to pull data from FoundScan, you must perform three tasks: 
e¢ Configure Foundstone FoundScan to correlate the required data, ensuring that the data is current. 
e Add the Foundstone FoundScan server to MARS using the web interface. 
e Schedule the interval at which the Foundstone FoundScan server data is pulled by MARS. 
This section contains the following topics: 
e Configure FoundScan to Generate Required Data, page 9-1 
e Add and Configure a FoundScan Device in MARS, page 9-2 


Configure FoundScan to Generate Required Data 


To configure FoundScan to provide data to MARS, follow these steps: 


Step 1 Run command svrneten at the DOS prompt on the host where FoundScan is installed. 
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ft Windos @ (Version 5.6 95] 
yright 1 8B Microsoft Corp. 


C:\Documents and ttings Administrator >srunetecn 
*syrunetcn’ not recognized as an internal or external connand, 
operable progran or batch file. 


>=\Documents and Settings\Adminicstrator>surnetcn 


; and Settings\Administrator>cd 


surnetcn 


143223 


Step2 _—_— In the SQL Server Network Utility dialog box, enable TCP/IP by moving TCP/IP from the Disabled 
Protocols list to Enabled Protocols list. 


| FSQt Server Ne x 


General | Network Libranes | 


Ipstance(s) on this server JEEYE zi 


Disabled protocols: Enabled protocols: 


Nwunk IPXSP Enable >» 
AppleT alk 
Bargan Vines << Disable 


vA 


Propesties 


t 
oK Cancel Apply Help 3 


I Force protocol encryption 
T Enable WinSock prowy 


Step 3 Click Apply. 


Add and Configure a FoundScan Device in MARS 


To add a FoundScan device in MARS, follow these steps: 


Step 1 Select Admin > Security and Monitor Devices > Add. 


Step2 Select Add SW Security apps on a new host or Add SW security apps on existing host from the 
Device Type list. 


Step3 Enter the device name and IP addresses if adding a new host. 
Step4 = Click Apply. 
Step5 Click the Reporting Application tab 
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Step 8 


Step 9 
Step 10 


eEyeREM1.0 il 


From the Select Application list, select Foundstone FoundScan 3.0 
Click Add. 


> *Database Name: 


> *Access Port: 1433 


—> *Access Type: 


Login: [ 


Password: [ 


143215 


Enter the following information: 
¢ Database Name—The name for this database. 
e Access Port—The default access port is 1433. 
e Access Type—Verify the value is MS SQL. 
e Login—The login information for the database. 
e Password—The password for the database. 
Click Submit. 
Click Apply. 


Once you activate this device (click Activate in the web interface), you must define the schedule at which 
MARS should pull data from it. For more information, see Scheduling Topology Updates, page 2-39. 


eEye REM 1.0 


To configure MARS to pull this REM data, you must perform three tasks: 
e Configure eEye REM to correlate the required data, ensuring that the data is current. 
e Add the eEye REM server to MARS using the web interface. 
e Schedule the interval at which the eEye REM server data is pulled by MARS. 
This section contains the following topics: 
e Configure eEye REM to Generate Required Data, page 9-3 
e Add and Configure the eEye REM Device in MARS, page 9-4 


Configure eEye REM to Generate Required Data 


Step 1 


To configure eEye REM to provide the correct data to MARS, follow these steps: 


Run command svrneten at the DOS prompt on the host where eEye REM 1.0 is installed. 
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MI scEye REM 1.0 


@ [Version 5.88 51] 
>-2888 Microsoft Corp. 


Documents and Settings\Administrator>erunetcn 


‘syvnetcn’ is not recognized as an internal or external connand, 


operable progran or batch file. 


C:\Documents and Settings\Administrator>surnetcn 


>\Docunents and Settings\Administrator>cd 


22\surnetcn 


Step 2 
Protocols list to Enabled Protocols list. 
_ a a a 
| ¥ SQL Server Nel xi 
General | Network Libraries | 
Ipstance(s) on this server JEEYE 7| 
Disabled protocols: Enabled protocols: 
Multiprotocol “ 
NWLink IPX/SPX Enable >> 
AppleT alk 
Baryan Vines << Disable 
VIA 
[ Force protecel encryption 
T Enable WinSock prony 
a 
oK Cancel Apply Help o 
Step3 = Click Apply. 


Add and Configure the eEye REM Device in MARS 


To add the eEye REM device in MARS, follow these steps: 


In the SQL Server Network Utility dialog box, enable TCP/IP by moving TCP/IP from the Disabled 


Step 1 Select Admin > Security and Monitor Devices > Add. 

Step2 Select Add SW Security apps on a new host or Add SW security apps on existing host from the 
Device Type list. 

Step3 = Enter the device name and IP addresses if adding a new host. 

Step4 = Click Apply. 

Step5 Click the Reporting Applications tab. 
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Step 6 
Step7 


Step 8 


Step 9 
Step 10 


Qualys QualysGuard Devices Hi 


From the Select Application list, select eEye REM 1.0. 
Click Add. 


> *Database Name: 
> *Access Port: [i433 —(‘CS;C‘*d 


> *Access Type: 


Login: 


Password: 


143215 


Enter the following information: 

¢ Database Name—The name for this database. 

e Access Port—The default access port is 1433. 

e Login—tThe login information for the database. 

e Password—tThe password information for the database. 
Click Submit. 
Click Apply. 


Once you activate this device (click Activate in the web interface), you must define the schedule at which 
MARS should pull data from it. For more information, see Scheduling Topology Updates, page 2-39. 


Qualys QualysGuard Devices 


wy 


In MARS, a QualysGuard device represents a specific report query to the QualysGuard API Server, 
which is the central API server hosted by Qualys. The only one that you configure to work with MARS 
is the QualysGuard API Server. You want to ensure that the QualysGuard API Server can provide reports 
about the devices on the network segments that you are monitoring with the MARS Appliance, as each 
MARS Appliance is responsible for identifying false positives for the network segments it monitors. 


If you have a subscription to the QualysGuard service, MARS can pull VA data from the QualysGuard 
database using the QualysGuard XML API, version 3.3. To configure MARS to pull this data, you must 
perform three tasks: 


e Configure QualysGuard to collect the required data, ensuring that the data is current. 
e Add the QualysGuard device that represents a report query to MARS using the web interface. 
e Schedule the interval at which the QualysGuard device data is pulled by MARS. 


Note 


If a proxy server resides between the QualysGuard server and the MARS Appliance, the settings defined 
on the Admin > System Parameters > Proxy Settings page are used. For more information, see Specify 
the Proxy Settings for the Global Controller or Local Controller, page 6-12. 
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This section contains the following topics: 
e Configure QualysGuard to Scan the Network, page 9-6 
e Add and Configure a QualysGuard Device in MARS, page 9-6 
e Schedule the Interval at Which Data is Pulled, page 9-8 
e Troubleshooting QualysGuard Integration, page 9-8 


Configure QualysGuard to Scan the Network 


MARS uses the QualysGuard XML API and password-based authentication over SSL (TCP port 443) to 
retrieve scan reports from the QualysGuard API Server. As such, you do not need to configure the 
QualysGuard server to accept connections from MARS. The only required configuration is that you have 
an active account and Qualys subscription that is configured correctly to scan your network. 


By default, MARS assumes that you want to retrieve the most recent scan report saved on the 
QualysGuard server. Depending on the number of IP addresses analyzed, the QualysGuard scan takes 
from a few seconds to several minutes. You need to estimate this time so that you can schedule automated 
scans of your network with a frequency that ensures a recent saved scan report is available. Using the 
QualysGuard administrative interface, you can determine how long a scan takes and set the schedule 
accordingly. 


Add and Configure a QualysGuard Device in MARS 


Step 1 
Step 2 


Step 3 


Adding an internal QualysGuard API Server as a reporting device entails identifying the server or 
appliance from which the reports are pulled and providing credentials that MARS can use to log in to 
the device to pull the reports. You can specify whether you want to pull saved scan reports that are run 
on a schedule or whether you want to initiate and retrieve an on-demand scan report. 


To add a QualysGuard device, follow these steps: 
Select Admin > Security and Monitor Devices > Add. 
Select QualysGuard 3.x from the Device Type list. 


Note; 
1. * denotes a required field. 


Device Type: | QualysGuard 3.x x 


> *Device Name:| ] 


> Access IP: 165.193.18.12 


> *URL: https Ag ualysapi.qualys.com/msp/scan_report_list.php?last=yes 


© Back Test Connectivity Submit 


Enter the name of the Qualys device in the Device Name field. 


143206 


User Guide for Cisco Security MARS Local Controller 
= 78-17020-01 | 


| Chapter 9 


Configuring Vulnerability Assessment Devices 


Step 4 


Step 5 
Step 6 
Step7 


Step 8 


Qualys QualysGuard Devices Hi 


This name is used to identify the Qualys device uniquely within MARS. It is used in reports and query 
results to identify this device. 


The IP address field is read only. The value is also fixed at 165.193.18.12, which is significant because 
you can only define one schedule for pulling all report queries defined as Qualys devices on the 

Local Controller. However, you can define unique schedules across different Local Controllers. For 
more information, see Scheduling Topology Updates, page 2-39. 


Enter the URL that identifies the device and report type in the URL field. 
The URL provides the following information: 


e Server. Identifies the server from which the report should be pulled. This value can be specified as 
a hostname or IP address that identifies the primary Qualys server. 


e Report type. Real-time vs. Last Saved. The default value. 
- Real-time Report. qualysguard.qualys.com/msp/scan.php?ip=[addresses | 
The addresses attribute specifies the target IP addresses for the scan request. 


IP addresses may be entered as multiple IP addresses, IP ranges, or a combination of the two. 
Multiple IP addresses must be comma separated, as shown below: 


123,123,123 .1,123 .123:.123:..4,123..123..123..5 


An IP address range specifies a start and end IP address separated by a dash (-), as shown below: 


123%.123 5.123) 1=123'.123'..123..:8 


A combination of IP addresses and IP ranges may be specified. Multiple entries must be comma 
separated, as shown below: 


123.123.123.1-123.123.123.5,194.90.90.3,194.90.90.9 


S 


Note You must use a Scanner Appliance to scan private IP addresses on your internal network. 


- Last Saved Report. qualysapi.qualys.com/msp/scan_report_list.php?last=yes 
Enter the username of the account that MARS will use to access the Qualys device in the Login field. 
Enter the password that corresponds to the account identified in Step 5 in the Password field. 


(Optional) To verify that the settings are correct and that the MARS Appliance can communicate with 
this Qualys device, click Test Connectivity. 


If you receive error messages during this test, refer to Troubleshooting QualysGuard Integration, page 
9-8. 

To add this device to the MARS database, click Submit. 

Once you activate this device (click Activate in the web interface), you must define the schedule at which 


MARS should pull data from it. For more information, see Schedule the Interval at Which Data is Pulled, 
page 9-8. 
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Schedule the Interval at Which Data is Pulled 


Once you activate one or more Qualys devices (where each device represents a report query run on the 
QualysGuard API Server), you must define the schedule at which MARS pulls data from them. The 
schedule, or update rule, that you define is the same for all Qualys devices. This update rule is based on 
the fixed IP address of 165.193.18.12, which is the Qualys Access IP. When you define an update rule 
using this address, all Qualys devices are updated based on that schedule. Even if you have more than 
one Qualys device on your network, you cannot stagger when MARS queries those Qualys devices. 
However, you can define unique schedules across different Local Controllers. 


For more information on the broader use of update rules, see Scheduling Topology Updates, page 2-39. 


To define the rule by which all Qualys devices will be discovered, follow these steps: 


Click Admin > Topology/Monitored Device Update Scheduler. 
The Topology/Monitored Device Update Scheduler page displays. 
Click Add. 

Enter Qualys Devices or another meaningful value in the Name field. 


This name identifies the rule in the list of rules that appears on the Topology/Monitored Device Update 
Scheduler page. 


Select the Network IP radio button, and enter 165.193.18.12. and 255.255.255.255 in the Network IP 
and Mask fields respectively. 


Click Add to move the device into the selected field. 
In the Schedule table, select Daily, and select a time value from Time of Day list. 


We recommend that you pull this data daily, during off-peak hours, however, you can define any interval 
required by your organization. 


Click Submit. 
The update rule appears in the list on the Topology/Monitored Device Update Scheduler page. 
Click Activate. 


To perform this discovery on demand, select the check box next to the rule you just defined and click 
Run Now. 


Troubleshooting QualysGuard Integration 


Table 9-1 identifies possible errors and likely causes and solutions. 
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Table 9-1 Error Table for QualysGuard and MARS Integration 

Error/Symptom Workaround/Solution 

Test connectivity failed. Click the This error means that MARS was unable to connect to the Qualys device. Four 
View Errors button for more possible issues can account for this message: 

information. 


e You have entered an invalid hostname or IP address in the URL field. Verify the 
Server unavailable. value was entered correctly. 


e The traffic may be blocked by either a proxy server or firewalls and gateways on 
your network. Enable SSL traffic (TCP port 443) to traverse between the MARS 
Appliance and the Qualys device. Enter the correct settings for your proxy server 
on the Admin > System Parameters > Proxy Setting page. 


Fail to parse scan report. This error means that MARS was unable to parse the scan report that it pulled from 
the Qualys device. Two possible issues can account for this message: 


e Data corruption on the QualysGuard device. 


e Format changes to the report due to an issue on the QualysGuard device or due 
to a software upgrade on the QualysGuard device. 


Verify that the QualysGuard device is running a supported version and that the device 
data is not corrupted. 


Invalid user credentials. This error means that MARS was unable to authenticate to the Qualys device. Two 
possible issues can account for this message: 


e The provided login credentials are incorrect. Verify these values were entered 
correctly, and verify that the provided account has sufficient privileges. 


e Your account has expired. Renew your subscription services with Qualys. 


Test connectivity failed for qualys. Make sure that the DNS server is configured correctly for the MARS Appliance. For 
Unknown host: qualysapi.qualys.com |more information on these DNS settings, see Specifying the DNS Settings, 
Please make sure that, page 5-15. 


e Proxy settings are configured 
correctly, If there is no direct 
connection exists from 
CS-MARS to Qualys server 


e The hostname specified in the 
URL string is correct 


e Login name and Password is 
valid. 
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Configuring Generic, Solaris, Linux, and 
Windows Application Hosts 


Application hosts are simply hosts on your network that are running important applications. Many of the 
supported reporting devices and mitigation devices cannot be represented in MARS until the base host 
on which they are running is defined. Examples of such applications include CheckPoint Firewalls and 
all forms of web servers. 


MARS provides for the definition of the following host types: 
e¢ Generic. Identifies no specific operating system, as well as any that are not directly supported. 
e Windows. Identifies one of the Microsoft operating systems. 
e Solaris. Identifies any of the Solaris family of operating systems. 
e Linux. Identifies any of the Linux family of operating systems. 


You should strive to define the application host as exactly as possible. This guideline applies to the 
vulnerability assessment information as well as the general settings. This detailed information helps 
MARS determine whether the host is susceptible to known attacks, such as those that specifically target 
on operating system or application/service running on the host. 


This chapter contains the following sections: 
e Adding Generic Devices, page 10-1 
e Sun Solaris and Linux Hosts, page 10-2 
e Microsoft Windows Hosts, page 10-4 


e Define Vulnerability Assessment Information, page 10-11 


Adding Generic Devices 


The MARS can support any syslog or SNMP devices, even if they do not appear on the list of devices 
supported by the MARS. You can enter any syslog or SNMP device into the network topology, configure 
it to report data to the MARS, and query it using a free-form query. For more information on free form 
queries, see To Run a Free-form Query, page 20-2. 
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Sun Solaris and Linux Hosts 


To configure MARS to receive and process Solaris or Linux host log information, you must perform 
three tasks: 


e Configure the Solaris or Linux Host to Generate Events, page 10-2 
e Configure Syslogd to Publish to the MARS Appliance, page 10-2 
e Configure MARS to Receive the Solaris or Linux Host Logs, page 10-3 


Configure the Solaris or Linux Host to Generate Events 


Step 1 


Step 2 


Step 3 


MARS Appliance can receive syslog information from a Linux/Solaris host. To configure the 
Linux/Solaris applications, you must configure the following applications to write to syslog: 


e xferlog 
e inetd 


To configure these applications to write to the system log, follow these steps: 


xferlog (which provides transfer logging information from the FTP server) 


For ftpd, add the following to /etc/ftpd/ftpaccess: 
log transfers real,guest,anonymous inbound,outbound log syslog+xferlog 


inetd trace messages (which provide the authentication information for services provided using inetd) 


For inetd, the line in /etc/rc2.d/S72inetsvc that reads: 
/usr/sbin/inetd -s 

needs to be changed to: 

/usr/sbin/inetd -t -s 


Other messages will automatically appear in the syslog and do not need to be specifically configured. 


Once you have enabled the message generation, you must configure the sylogd deamon to publish 
messages to the MARS Appliance. For more information, see Configure Syslogd to Publish to the MARS 
Appliance, page 10-2. 


Configure Syslogd to Publish to the MARS Appliance 


Step 1 


Step 2 


Once you have enabled the correct applications to write to the system log, you must configure the syslog 
daemon on the Solaris or Linux host to publish syslog messages to the MARS Appliance. 


To configure the Solaris or Linux host to publish syslogs to the MARS Appliance, follow these steps: 


Edit /etc/syslog.conf file and add the line below: 


* debug @MARS_hostname 


where MARS_hostname is the hostname or IP address of the MARS Appliance. 


Run following commands to restart syslogd so that the changes are process: 


/etc/init.d/syslog stop 
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/etc/init.d/syslog start 


Once this line is added to the syslog.conf file and you have restarted syslogd, any messages sent to 
console are also sent to the MARS Appliance. 


Configure MARS to Receive the Solaris or Linux Host Logs 


To add a generic device to MARS, follow these steps: 


Step1 Click Admin > Security and Monitor Devices > Add. 


Figure 10-1 Adding a Generic Device 


Device Type:| Cisco IDS 3.1 


Noy 


N 


-0 
| 
2 
3 


; Cisco PIX 6. 
Report cisco Switch-CatOS ANY 


Cisco Switch-IOS 12.2 
|Cisco VPN Concentrator 4.x 
Extreme ExtremeWare 6.x 
Generic Router version unknown 
Login;|NetScreen ScreenOS 4.0 
NetScreen ScreenOS 5.0 
Network Appliance NetCache Generic 


143270 


Step2 From the Device Type list, select Add SW Security apps on a new host. 
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Step 3 
Step 4 
Step 5 
Step 6 


Figure 10-2 Adding a Generic Device to receive logs 
% 
General Reporting Applications ¥ulnerability Assessment Info 


> *Device Name: 


> Access IP: | ee; | | 
> Reporting IP: | | { 
> Operating System:[Generic [+] 
> NetBIOS Name: [sid 


> Monitor Resource |pnjo + 
Usage: 


Enter interface information: 


Add Interface Remove Interface/IP 


Name: IP Address: Network Mask: 


Pe) 990) I na ener rast] 
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Enter the Device Name, and its Reporting IP address. 
Select Operating System as Generic. 
Select Logging Info and select Receive, then click Submit. 


Click Apply to add the device. 


Microsoft Windows Hosts 


MARS processes data pulled from hosts running Microsoft Windows. This data includes the events 
found in the security event log as well application event and system event logs. You can use one of two 
methods to retrieve the logs from a host running Microsoft Windows, whether it is a server or 
workstation version: 


e You can configure MARS to pull the logs from the host. 
e You can configure the host to send the log data to the MARS Appliance. 


These two methods are mutually exclusive; in other words, you cannot configure both methods. Your 
decision in which method to use depends on how much time you can spend preparing the host, the 
desired load on the MARS Appliance, and how near real-time you want MARS to process the event data. 


The pull method not only requires system resources for correlating, but also for contacting and pulling 
the event data from each host. It also operates in a single process, completing the pull from one device 
before moving to the next. As a result, the pull method may take much longer to cycle through all of the 
reporting devices as the number of devices grows. 
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The push method is more efficient in terms of resource utilization on the MARS Appliance and in terms 
of how quickly the MARS Appliance can be made aware of event data, but it requires that you install 
and configure the Snare Agent for Windows on the Microsoft Windows host. The Snare Agent pushes 
event data form the servers to MARS in near real time, when an audit event occurs, the agent sends a 
syslog message to MARS that details the event. It is also more efficient and timely in that each Snare 
Agent is able to act independently rather than being bound by a single process as with the pull method. 


The following sections describe these two methods: 
e Push Method: Configure Generic Microsoft Windows Hosts, page 10-5 
e Pull Method: Configure the Microsoft Windows Host, page 10-6 


Push Method: Configure Generic Microsoft Windows Hosts 


MARS can treat hosts running Microsoft Windows as reporting devices, monitoring the event log data 
generated by the host. The host needs to run InterSect Alliance SNARE Agent for Windows, which 
captures event log data and sends it to MARS. The push method requires four steps: 


1. Install the SNARE agent on the Microsoft Windows host. For more information, see Install the 
SNARE Agent on the Microsoft Windows Host, page 10-5. 


2. Configure the SNARE agent to forward event data to the MARS Appliance. For more information, 
see Enable SNARE on the Microsoft Windows Host, page 10-6 


3. Ensure that UDP 514 traffic can pass between the hosts and the MARS Appliance. 


4. Identify that host in MARS so that it can correctly parse and correlate the event data. For more 
information, see Configure the MARS to Pull or Receive Windows Host Logs, page 10-8. 


Install the SNARE Agent on the Microsoft Windows Host 


Step 1 


Step 2 


Step 3 
Step 4 
Step 5 
Step 6 
Step7 
Step 8 
Step 9 


Step 10 


To install the SNARE agent, follow these steps: 


Log in to the target host using a username with proper administrative privileges. 
The username must have the permission to publish audit data as well as to install new programs. 


Download the SNARE Agent for Windows from the following URL that corresponds to the operating 
system type installed on the target host: 


http://www. intersectalliance.com/projects/Snare Windows/index.html#Download 
Double-click the SnareSetup<version>.exe file to start the install program. 
Click Next. 
Select the target install folder and click Next. 
Select Normal Installation in the Components list and click Next. 
Select the target Start menu location and click Next. 
Verify the selection options and click Install. 


SNARE is installed and started on the local host. A dialog box appears, prompting you to specify 
whether to allow SNARE to control the EventLog configuration for the Microsoft Windows host. 


Select Yes to enable SNARE to control the EventLog configuration for this Microsoft Windows host. 


The SNARE - Remote Event Logging for Windows user interface appears. 
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Step11. To configure the Snare agent, continue with Enable SNARE on the Microsoft Windows Host, page 10-6. 


Enable SNARE on the Microsoft Windows Host 


Once you have downloaded and installed the SNARE agent on the target Microsoft Windows host, you 
must configure the agent to forward the correct event data in the correct format to the MARS Appliance. 


wy 


Note The first time you install SNARE, a dialog box appears asking “Do you want Snare to take over control 
of your Event Log?” Select Yes. 


To configure the SNARE agent, follow these steps: 


Step1 Click All Programs > InterSect Alliance > Snare for Windows to run the SNARE - Remote Event 
Logging for Windows user interface. 


Step2 =‘ The first time you install SNARE, a dialog box appears asking “Do you want Snare to take over control 
of your Event Log?” Select Yes. 


Step3 Click Setup > Audit Configuration.... 
The Audit Configuration dialog box appears. 
Step4 Specify values for the following fields: 
e Enter the local host name. Specify the IP address or DNS name of the local host in the field. 


e Enter the snare server ip or dns addr. Specify the IP address or the DNS name of the MARS 
Appliance. 


Step5 =‘ Verify that the following options are selected: 
e Enable SYSLOG header 
e Automatically set audit configuration 
e Automatically set file system audit configuration 
Step6 Click OK to close the Audit Configuration dialog box and save your changes. 
Step7 Click File > Exit to close the SNARE - Remote Event Logging for Windows user interface. 


The Snare agent is stopped and restarted to pick up the configuration changes. 


Pull Method: Configure the Microsoft Windows Host 


As an alternative to the push method, you can configure MARS to pull event log data (security, 
application, and system event logs) from Microsoft Windows hosts. The pull method requires four steps: 


1. Ensure that the Windows host and MARS Appliance clocks are synchronized. It is recommend that 
you configure a NTP server for this purpose. For more information, see Specify the Time Settings, 
page 5-10. 


1. Select an existing or define a new user account on the Windows host that the MARS Appliance can 
use to pull event log records. 
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2. Ensure that the user account has the correct credentials. Verify that the user account belongs to the 
Administrator group and verity the it includes the privilege for managing and auditing security logs. 
For more information, see the procedure that corresponds to the operating system running on the 
host: 


- Enable Windows Pulling Using a Domain User, page 10-7 

- Enable Windows Pulling from Windows NT, page 10-7 

- Enable Windows Pulling from a Windows 2000 Server, page 10-7 

- Enable Windows Pulling from a Windows Server 2003 or Windows XP Host, page 10-8 
3. Configure the Windows host to generate the correct event data. 


4. Identify that host in MARS so that it can correctly parse and correlate the event data. For more 
information, see Configure the MARS to Pull or Receive Windows Host Logs, page 10-8. 


5. Specify the time interval at which the event log data should be pulled from all identified host running 
Microsoft. For more information, see Windows Event Log Pulling Time Interval, page 10-10. 


Enable Windows Pulling Using a Domain User 


Step 1 


Step 2 


To enable Windows pulling using a domain user (domain\username), for example, CORP\syslog, do 
the following on the domain controller before you enable Windows pulling on your client: 


On the domain controller, click Administrative Tools > Default Domain Security Policy > Security 
Settings > Local Policies > User Rights Management. 


Grant the permission Manage auditing and security log to the domain user (domain\username). 


Enable Windows Pulling from Windows NT 


Step 1 
Step 2 


Step 3 


To enabled MARS to pull event log data from a Windows NT host, follow these steps: 


From Start > Programs > Administrative Tools > User Manager, in the menu bar, choose Policies. 


In the submenu, choose User Rights, make sure the right of Manage auditing and security log is 
granted to the user account used for pulling event log records. 


In the submenu, choose Audit. Configure the audit policy according to your site’s security auditing 
policy. 


Enable Windows Pulling from a Windows 2000 Server 


Step 1 


When there is no Active Directory Service (ADS) server sending domain information to your Windows 
2000 server, you must set this property to Disabled on each host from which you want the MARS 
Appliance to pull syslogs. 


To enabled MARS to pull event log data from a Windows 2000 host, follow these steps: 


Go to Start > Settings > Control Panel > Administrative Tools > Local Security Policy. 
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Step 2 


The Local Security Settings applet appers. 
Configure the settings under the following Local Policy groups as specified: 
e Security Settings > Local Security Policy > User Rights Mangamement 


Make sure the right of Manage auditing and security log is granted to the user account used for 
pulling event log records. 


e Security Settings > Local Security Policy > Audit Policy 


Configure the audit policy according to your site’s security auditing policy and ensure that all entries 
under Effective Setting are set to Success, Failure. 


Enable Windows Pulling from a Windows Server 2003 or Windows XP Host 


wy 


Note 


Step 1 


Step 2 


S 


If you are selecting Microsoft Windows XP Home Edition, you must enable the Remote Procedure Call 
services under All Programs > Control Panel > Administrative Tools > Services. This service is enabled 
by default on Windows XP Professional. 


To enabled MARS to pull event log data from a Windows Server 2003 or Windows XP host, follow these 
steps: 


Go to Start > Settings > Control Panel > Administrative Tools > Local Security Policy. 
The Local Security Settings applet appers. 
Configure the settings under the following Local Policy groups as specified: 

e Security Settings > Local Security Policy > User Rights Mangamement 


Make sure the right of Manage auditing and security log is granted to the user account used for 
pulling event log records. 


e Security Settings > Local Security Policy > Audit Policy 


Configure the audit policy according to your site’s security auditing policy. 


Note 


The pulling of an event log itself generates security event logs if certain events, such as Log on/off, are 
audited. We recommend you either set a default domain policy, or set the retention method for security 
event logs on your Windows system to be Overwrite as needed. Otherwise, when the log is full no new 
event log can be generated on the Windows system. 


Configure the MARS to Pull or Receive Windows Host Logs 


Step 1 


Once you’ve prepared the Microsoft Windows host, you must identify that host in MARS and identify 
whether the push or pull method is being used on that host. 


To configure the MARS Appliance to either pull or receive logs, follow these steps: 


Select Admin > Security and Monitor Devices > Add 
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Step 2 


Step 3 
Step 4 
Step 5 


Step 6 
Step7 


S 


Microsoft Windows Hosts Mil 


From the Device Type list, select Add SW Security apps on a new host or Add SW security apps on 
existing host. 


Enter the Device Name and IP addresses if adding a new host. 
Select the Operating System > Windows from the list. 
(Optional) Enter NetBIOS name. 


Figure 10-3 Window Log Configuration 
| General | Reporting Applications ¥ulnerability Assessment Info 
> *Device Name: Softie III 


> Access IP: [is2 |[te 2 |e] 
> Reporting IP: 192 fies Jz |fs__] 


=> Operating System: 


Windows » 


Logging Info 


> NetBIOS Name: netBIOS_Name| 


> Monitor Resource [yo ¥ 
Usage: 


Enter interface information: 


| Add Interface Remove Interface/IP | 
Name: IP Address: Network Mask: 
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Click on Logging Info to configure OS Logging Information. New pop-up window will appear. 


From the Windows Operating System, select the correct option for either the server or workstation 
version: 


e Microsoft Windows 2000 
e Microsoft Windows 2003 (Also used for Microsoft Windows XP platforms.) 
e Microsoft Windows Generic 


e Microsoft Windows NT 


Note _If you are selecting Microsoft Windows XP Home Edition, you must enable the Remote Procedure Call 
services under All Programs > Control Panel > Administrative Tools > Services. 
Step8 Select either the Pull or the Receive checkbox, based on the host configuration that you have performed. 
Caution Do not select both checkboxes. Doing so generates unpredictable results. 
Step9 — If you selected the Pull method, enter values for the following fields: 
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¢ Domain name—lIdentifies the domain name to which the host belongs. 
¢ Host login—Identifies the username with security audit and log permissions. 


e Host password—lIdentifies that password that authenticates the username provided in the Host 
login field. 


Step10 Click Submit. 


Figure 10-4 Windows Logging 


OS Logging Information 


Windows Operating System: Microsoft Windows 2003 
Logging mechanism: Jv Pull [7 Receive 
Domain Name: [my_domain | 
Host login: 
Host password: 


143262 


Cancel Submit 


Step11. Click Submit to save your changes. 
Step 12 Add Interface IP Address and Network Mask. 
Step13 Click Apply. 


Step14 Click the Vulnerability Assessment Info link to define the host information that MARS uses to 
determine false positive attacks against this host. Continue with Define Vulnerability Assessment 
Information, page 10-11. 


Step15 Click Done to save the changes. 
Step16 To activate the device, click Activate. 


If you selected the pull check box in Step 8, verfiy that a value has been specified for the interval at 
which which MARS pulls an event log from the host. For more information, see Windows Event Log 
Pulling Time Interval, page 10-10. 


Windows Event Log Pulling Time Interval 


You can now set the interval at which MARS pulls an event log from all Microsoft Windows host that 
are defined as reporting devices. This feature determines how often MARS requests logs from the 
Windows hosts that are configured a reporting devices. 


Note If you are using SNARE to push the log data to MARS, then you do not need to enable this setting. 


To configure the Windows event log pulling time interval, follow these steps: 
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Step 1 


Step 2 
Step 3 


Define Vulnerability Assessment Information [i 


Click Admin > System Parameters > Windows Event Log Pulling Time Interval. 


Windows Event Log Pulling Time Interval 


Windows Event Log |300 (secs) 
Pulling Time Interval: 


143186 


| © Back | Submit 


Enter the new time interval in seconds. The default value is 300 seconds (five minutes). 


Click Submit. 


Define Vulnerability Assessment Information 


Step 1 


Step 2 


For each host that you define in MARS, you can specify information about that host that assists MARS 
in assessing whether that host is vulnerable to the attacks that MARS detects. For example, you can 
identify the operating system running on the host, even providing the latest or nearest patch level. When 
an attack is detected that is targeted toward a specific operating system, then MARS can quickly 
determine whether the host is running the operating system that is targeted. 


For hosts that are defined as the base platform of a reporting device, you should define this information 
as part of that device definition. 


However, as MARS, it begins to add discovered hosts to the list of hosts under Management > IP 
Management. You should periodically review these hosts to update their information if you do not have 
a vulnerability assessment software device or service, such as Qualys QualysGuard, running on your 
network. 


To specify the vulnerability assessment information for a host, follow these steps: 


To select the desired host, do one of the following: 


e Select Management > IP Management, select the check box next to the desired host, and click 
Edit. 


e Select Admin > Security and Monitor Devices, select the check box next to the desired host, and 
click Edit. 


Click the Vulnerability Assessment Info tab. 
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Step 3 


Step 4 


Step 5 


Step 6 
Step 7 


Figure 10-5 Vulnerability Assessment Info for a Host 


g 


General ¥ulnerability Assessment Info 


Specify OS and patch Information 


@ Select operating system from: 


>o00f ; in: 5.0.4.2195,patch: SP 4) | jv Allow Overwrite with ¥A 


c¢ Define new operating system: 


Current running services: 


Add New Service Delete Service 


Done Apply 


Under Specify OS and patch Information, do one of the following: 


Select Select operating system from, and then select the operating system that matches the one 
running on this host from the list. Continue with Step 4. 


Select Define new operating system, and continue with Step a.. 

Enter the name of the operating system in the Name field. 

Enter the version number for this operating system in the Version field. 
Enter the patch level associated with the version number the Patch field. 
Enter the name of manufacturer of the operating system in the Vendor field. 
Click Apply to save the operating system definition. 


Result: The new operating system definition is added to the Select operating system from list, and 
it is the selected option. 


If you define a custom operating system, you must select Generic in the Operating System list on 
the General page of the host and click Apply. Otherwise, you cannot select the new operating system 
in the Select operating system from list. 


To allow the information that you provided to be overridden by a vulnerability assessment service 
running on your network, select the Allow Overwrite with VA checkbox. 


To add more detailed information about the host, continue with Identify Network Services Running on 
the Host, page 10-13. 


Click Apply to save the changes made to this host. 


Click Done to close the Host page 
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Identify Network Services Running on the Host 


By identifying the network services that are running on a host, you are specifying the types of network 
activities that you expect for this host. This data is helpful in eliminating expected activities that might 
otherwise be flagged as suspicious by MARS; for example, if you have administrative servers that run 
network discovery applications or perform vulnerability assessment probes at scheduled times. 


To identify the network services running on a host, follow these steps: 


Step 1 To select the desired host, do one of the following: 
e Select Management > IP Management, select the check box next to the desired host, and click 
Edit. 
e Select Admin > Security and Monitor Devices, select the check box next to the desired host, and 
click Edit. 
Step2 Click Add New Service under Current running services. 
S 
Note It may take five minutes or more for this dialog box to load. You can place the cursor over the title bar 
of the window that opens. This allows you to see if the window is still loading. 
Step3 Enter as much detail on the service and its applications as you can. 
e You can choose between selecting a service and defining a new service. 
e You can also choose between select an application or defining a new application. 
Step4 Click Submit. 
Step5  §=You can enter more services here by clicking Add New Service, or you can click Submit to continue. 
Step6 Click Submit to complete the addition of the host. 
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Configuring Database Applications 


Database applications are typically high-value assets, and as such, they are common targets for attacks. 
Database applications provide MARS with user activity, such as successful and failed login attempts, 
session durations, and activities indicative of privilege escalation. 


This chapter explains how to bootstrap and add the following database applications to MARS: 


e Oracle Database Server Generic, page 11-1 


Oracle Database Server Generic 


To configure CS-MARS to collect information from the Oracle database server, you must perform three 
tasks: 


¢ configure the Oracle database server to generate a audit trail and record those events the database. 
e represent the device in the web interface 
¢ configure the interval at which CS-MARS should pull the logs from the Oracle database server. 


Configuring the pull interval is a one-time operation that applies to all of the Oracle database servers 
monitored by the MARS Appliance. 


This section contains the following topics: 
e Configure the Oracle Database Server to Generate Audit Logs, page 11-1 
e Add the Oracle Database Server to MARS, page 11-2 
e Configure Interval for Pulling Oracle Event Logs, page 11-3 


Configure the Oracle Database Server to Generate Audit Logs 


You must configure the Oracle database server to write audit logs to the database. You may need your 

DBA support to perform most of these configurations. Once configured, MARS can retrieve the audit 

logs from your Oracle database server. The following examples are for an Oracle instance running on a 
UNIX/Linux application host. 


To configure an Oracle database server to write audit logs, follow these steps: 


Step 1 As sysdba execute cataudit.sql to create audit trail views: 


[oracle@server]$ sqlplus /nolog 
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SQL> conn / as sysdba; 
SQL> @SORACLE_HOME/rdbms/admin/cataudit.sql 
Step2 Enable auditing to the database by adding the following entry to the Oracle instance initialization file, 
usually named init<SID>.ora 


AUDIT_TRATIL=DB 


This file is usually located in $0RACLE_BASE/admin/<SID>/pfile, where <SID> is the name of the 
Oracle instance. 


If a binary initialization file is used for this instance, make sure you update it first. This file is usually 
located in $;0RACLE_HOME/dbs and named spfile<SID>.ora. Ask your DBA about the location of 
these files as well as the policies applied for this server. 


Step3 —_ Restart the database to activate the change made to the initialization file. 


[oracle@server]$ sqlplus /nolog 
SQL> conn / as sysdba; 
SQL> shutdown immediate; 


SQL> startup; 


Step4 =‘ Turn on all the logs that you want to audit. The following example is turning on the “audit session”. 


SQL> audit session; 
Audit succeeded. 


Step5 Repeat the previous step for all the logs that you want to audit. 


Step6 | Create a user account on this server and grant select privilege for the view dba_audit_trail. Our example 
assumes the user has login name “pnuser”. 


SQL> grant select on dba_audit_trail to pnuser 


You’ll use “pnuser” as the value for “User Name” in the MARS setup. 


Step7 To test that everything was properly configured, audit logs are written to the database and “pnuser” has 
read access to them, execute the following commands: 


[oracle@server]$ sqlplus pnuser/<password>@<oracle_server> 


SQL> select count(*) from dba_audit_trail; 


If the above count is anything but zero, congratulations, you have successfully configured the Oracle 
Server! You will have to repeat the above procedure for every Oracle server that you want to report audit 
logs to MARS. 


Add the Oracle Database Server to MARS 


To represent the Oracle database server in the web interface, follow these steps: 


Step1 Click Admin > Security and Monitor Devices > Add. 
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Step 2 


Step 3 
Step 4 
Step 5 
Step 6 


Step7 


Step 8 
Step 9 


Oracle Database Server Generic [il 


From the Device Type list, select Add SW Security apps on a new host or Add SW security apps on 
existing host. 


Enter the Device Name and IP addresses if adding a new host. 


Click Apply. 
From the Select Application list, select Oracle Database Server Generic. 
Click Add. 
User Name: 
Password: | 
Protocol: 
Port: (Default:1521) 
Oracle Service Name: 
Audit View: DBA_AUDIT_TRAIL 
oS 
NN 


Enter the User Name, Password and Oracle Service Name 
e User Name -— the Oracle Database User Name 
e Password — the Oracle Database User password 
e¢ Oracle Service Name — the Oracle Service Name 


The Oracle Service Name is the GLOBAL_DBNAME=username.server which can be found inside a file 
called listener.ora. 


Click Test Connectivity to verify the configuration. 
Click Submit. 


Configure Interval for Pulling Oracle Event Logs 


Step 1 


To specify the interval at which MARS should pull the event logs from all Oracle database servers on 
your network, follow these steps: 


Click Admin > System Parameters > Oracle Event Log Pulling Time Interval. 
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Oracle Event Log Pulling Time Interval 


Oracle Event [sag] sees) 
Log Pulling 
Time 


Interval: 
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Step 2 Enter the new time interval in seconds. The default value is 300 (five minutes). 


Step3. Click Submit. 
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Configuring Web Server Devices 


To use web logging with MARS, you need to configure the host, the webserver, and MARS. MARS can 
process up to 100 MB of web log data per receive from your host. 


Note 


Web logging is only supported on hosts running Microsoft HS on Windows, Apache on Solaris or Linux, 
or iPlanet on Solaris. 


This chapter explains how to bootstrap and add the following web sever devices to MARS: 
e Microsoft Internet Information Sever, page 12-1 
e Apache Web Server on Solaris or RedHat Linux, page 12-7 


e Sun Java System Web Server on Solaris, page 12-7 


Microsoft Internet Information Sever 


You can add computers running Microsoft Windows to MARS as reporting devices. The Microsoft 
Windows computer needs to run InterSect Alliance SNARE for IIS, from which MARS receives web log 
data. 


Note 


Synchronize clocks of the Microsoft Windows system and the MARS to ensure times match between 
them. 


Install and Configure the Snare Agent for IIS 


Step 1 


To configure IIS to publish logs to MARS, you must install and configure a log agent. This agent is free 
from the InterSect Alliance. You can download the Snare Agent for IIS Servers from the following URL: 


http://www.intersectalliance.com/projects/SnarelIS/index.html#Download 


After you have downloaded and install the SNARE on the the Windows webserver, you can continue with 
the procedures in this section that detail the correct configuration for MARS, 


To configure SNARE for web logging, follow thees steps: 


Click Start > Programs > InterSect Alliance > Audit Configuration. 
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Figure 12-1 Configure SNARE for Web Logging 


Balsnaretis - audit Service Con 


INTER ocr 


ALLIANGE 


Snare for IIS - IIS Log to Syslog Service 
InterSect Alliance Pty Ltd - www. intersectalliance.com 


Target Host: fi 0.2.3.43 
Log Directory [CAWINNT \System32\LogFiles', 


Destination @ Syslog Custom Port feet 


Syslog Category: [User he |[Notice = | 


Delimiter: @ TAB © Comma © Other fi 
Headers: T~ Display IIS Header information 


The SnarellS Service must be restarted to enable changes. 


OK | Cancel | 


Step2 In Target Host enter the IP address of the MARS. 
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Step3 _—_ In Log Directory, enter the directory where the logs are to be placed. 
Step4 _In Destination, click the Syslog radio button. 
Step5 Click OK. 


To configure IIS for web logging 


Step1 Click Start > Programs > Administrative Tools > Internet Services Manager. 
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Figure 12-2 Configure IIS for Web Logging 


Microsoft Internet Information Sever 


¢ Internet Information Services 


Internet Information Services 
‘& * office 


3 Default FTP Site 


+ 
+) Administration Web Site 
)-y Default SMTP Virtual Server ( 
#)-i¢ Default NNTP Virtual Server 


+} 


(Scripts c:\inetpub\scripts 
@Buustelp c:\winnt\help\iishelp lt 


C\WINNT\System32\inetsrv\iisadmin 
c:\inetpub\iissamples 

c:\program Files\common files\system\msadc 
C:\Program Files\Common Files\Microsoft Shared\wWeb 
C:\WINNT\web\printers 
C\WINNT\System32\RpcProxy 
C:\WINNT\system32\CertSrv 
C:\WINNT\system32\CertSrv\CertControl 
C\WINNTisystem32\CertSrv\CertEnroll 
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Step2 In the Tree tab on the left, right-click Default Web Site. 


Step3 On the shortcut menu, select Properties. 


Figure 12-3 


Enable Logging 


Detaukk Web Site Properties 
Directory Security | HTTP Headers | Custom Errors | Server Extensions | 
Web Site | Operators | Performance | ISAPI Filters | Home Directory | Documents | 


Web Site Identification 


Description: 


TCP Pott: [e080 


IP Address: [{All Unassigned) x] Advanced... | 


ssLPot [| 


Connections 
© Unlimited 
© Limited To: 


IV HTTP Keep-Alives Enabled 


j 1,000 | connections lt 
Connection Timeout: | 300 seconds 


> Enable Logging 


Active log format: 


Cancel | Apply | Help | 


fwac Extended Log File Format 7] Propetties... | 
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Step4 Inthe Web Site tab: 
a. Make sure Enable Logging is checked. 
b. From the Active log format list, select W3C Extended Log Format. 
c. Click Properties. 


Figure 12-4 Select General Log Settings 


Extended Logging Properties ‘ x! 


General Properties | Extended Properties | 


> New Log Time Period 
™ Hourly 

@ Daily 

C Weekly 

© Monthly 

© Unlimited file size 

© When file size reaches: 


fi 3 4 MB 


[~ Use local time for file naming and rollover 


Log file directory: 


[wind ir%\System32\LogFiles Browse... | 


Log file name: 9=W3SVC1\expymmdd.log 


143259 


Cancel | Apply | Help | 


d. In the General Properties tab, set the New Log Time Period to Daily. 


wy 


Note The Log file directory must match the one previously set using the Audit Configuration program. 


e. In the Extended Properties tab, make sure all available properties are selected. 
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Step 5 


Figure 12-5 Select Extended Log Events 


Extended Logging Properties a 


General Properties Extended Properties | 


f. 


> Extended Logging Options it 


i] Sf 


[¥] Protocol Status [ sc-status ] 
¥) Win32 Status [ sc-win32-status ] 


nd 
oe a 


) Time [time } 
Extended Properties 
(| Client IP Address [ c-ip 
¥) User Name [ cs-username ] 
¥) Service Name [ s-sitename } 
V7) Server Name [ s-computername } 
¥) Server IP Address [s-ip } 


<) 


Server Port [ s-port ] 
Method [ cs-method } 
URI Stem [ cs-uri-stem J 
URI Query [ cs-uri-query } 


Cancel | Apply | Help | 


Click OK. 


Click OK. 


MARS-side Configuration 


To add configuration information for the host 


Step 1 
Step 2 


Step 3 
Step 4 
Step 5 
Step 6 
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Click Admin > Security and Monitor Devices > Add 


Microsoft Internet Information Sever 


From the Device Type list, select Add SW Security apps on a new host or Add SW security apps on 
existing host 


Enter the Device Name and IP Addresses if adding a new host. 


Select the Windows from Operation System list 


Click Logging Info 


For this configuration, you must check the Receive host log box 
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Figure 12-6 Windows Web Server Logging mechanisms 


OS Logging Information 


Windows Operating System: 


Logging mechanism: |v Pull [7 Receive 
Domain Name: 
Host login: 

Host password: 
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Cancel Submit 


Step 7 Click Submit. 
Step8 Continue adding the interfaces. 
e For the first interface, enter its name, IP address, and mask. 
e For multiple interfaces, click Add Interface, and add each new interface’s name, IP address, and 
mask. 
Step9 Add as many IP addresses and masks to the interface as you need by clicking Add IP/Network Mask. 
Step10 Click Apply. 
Step11 Click Reporting Applications tab. 


Step12 From the Select Application list, select Generic Web Server Generic. 


Step13. Click Add. 


Figure 12-7 Selecting the Windows Web Log format 


Web log format: | one 
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Step14. Select W3C_EXTENDED_LOG format 
Step15 Click Submit. 


Note Once you have configured and activated both sides, it takes two pulling intervals (default time of 10 
minutes) before new events appear. 
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Apache Web Server on Solaris or RedHat Linux Hi 


Apache Web Server on Solaris or RedHat Linux 


Sun Java System Web Server on Solaris 
%, 


Note The Sun Java System Web Sever was formerly known by the following product names: Netscape 
Enterprise Server, iPlanet Web Server, and Sun ONE Web Server, 


Generic Web Server Generic 


You can add computers running Solaris or Linux to MARS as reporting devices. The computer needs to 
run an opensource agent that sends web log data to MARS. 


Solaris or Linux-side Configuration 
Cisco provides an opensource logging agent and an associated configuration file for you to use. This 
agent can be downloaded from the software download center at the following URL: 
http://www.cisco.com/cgi-bin/tablebuild.pl/cs-mars-misc 


wy 


Note Synchronize clocks of the UNIX or Linux system and the MARS to ensure times match between them. 


Install and Configure the Web Agent on UNIX or Linux 


For MARS to recieve logs from a webserver, you must install the Web agent, (agent.pl version 1.1) on 
the target webserv and direct the agent to publish logs to the MARS Appliance. 


S 


Note Before you install the agent, you must have perl and curl installed on your system. 


To install the agent on a UNIX or Linux hosts, follow these steps: 


Step 1 Log into the host as the root user. 

Step2 Create a directory called /opt /webagent. 

Step 3 Copy the files agent.pl andwebagent.conf tothe /opt/webagent directory. 
Step4 Set the protection of the agent script (agent .p1) so it can be read and executed by all: 


cd /opt/webagent 
chmod 755 agent.pl 


Step 5 Edit the configuration file (weblogagent.conf): 


logfile_location = access_log_path 
MARS_ip_port = MARS_ip_ address 
username = a 
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password = b 


Where the following values are provided: 
e access_log_path identifies the absolute path name to the web server’s access log 
e MARS_ip_address is the IP address of the MARS Appliance 


You do not need to edit the username or password in the file. 


Note 


Step 6 


You need a separate weblogagent.conf file for each access log you want to pull. We recommend 
naming them weblogagent1.conf, weblogagent2.conf, and so forth. Put these in the 
/opt/webagent directory also. 


To run the agent using a configuration file other than weblogagent. conf, use the command: 


agent.pl other_config_file 


replacing other_config_ file with the name of the web agent configuration file. 


Edit the crontab file to push the logs to the MARS at regular intervals. The following example gets new 
entries from the access log and pushes them to MARS every five minutes: 


crontab -e 
S10, 15,20,25750,35, 40,45 50,5505 #.* 

(cd /opt/webagent;./agent.pl weblogagent1.conf) 
5, 10, 15,20,25,30,35,40,45,50, 55,0" * * *>* 

(cd /opt/webagent;./agent.pl weblogagent2.conf) 


Web Server Configuration 


To configure the Apache web server for the agent 


Step 1 


Step 2 


In the file httpd.conf, make sure the LogFormat is either common or combined and matches the 
format set on the MARS. 


Stop and restart the Apache server for your changes to take effect. 


To configure the iPlanet web server for the agent 


Step 1 
Step 2 
Step 3 
Step 4 
Step 5 
Step 6 


In the iPlanet server administration tool, click the Preferences tab. 

In the left menu, click the Logging Options link. 

Make sure the Log File matches the log file name set on the MARS. 

Make sure the Format radio button Use Common Logfile Format is checked. 
If you have made any changes, click OK. 


If necessary, shut down and restart the iPlanet web server. 
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MARS-side Configuration 


To add configuration information for the host 


Step 1 
Step 2 


Step 3 
Step 4 
Step 5 
Step 6 


Step7 
Step 8 


Step 9 

Step 10 
Step 11 
Step 12 
Step 13 


Click Admin > Security and Monitor Devices > Add. 


Generic Web Server Generic 


From the Device Type list, select Add SW Security apps on a new host or Add SW security apps on 


existing host. 
Enter the Device Name and IP Addresses if adding a new host. 
Select the either Solaris or Linux from Operation System list. 


Click Logging Info. 


For this configuration, you must check the Receive host log box. 


Figure 12-8 Unix or Linux Web Server Logging mechanism 


OS Logging Information 


Logging mechanism: |; Pull (7 Receive 


Host login: 
Host password: = [id 
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Click Submit. 
Continue adding the interfaces. 


e For the first interface, enter its name, IP address, and mask. 


e For multiple interfaces, click Add Interface, and add each new interface’s name, IP address, and 


mask. 


Add as many IP addresses and masks to the interface as you need by clicking Add IP/Network Mask.. 


Click Apply. 
Click Reporting Applications tab. 


From the Select Application list, select Generic Web Server Generic. 


Click Add. 


Figure 12-9 Linux Operating System Web Log Format 


Web log format: | None 


SQUID_LOG 


NETSCAPE_EXTENDED_LOG 
NETCACHE_WEB_ACCESS_DEFAULT_LOG 
W3C_EXTENDED_LOG 
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Step14 From the Web Log Format list, select appropriately. 
Step15 Click Submit. 


wy 


Note Once you have edited a device you must click Activate for the changes to take effect. 


User Guide for Cisco Security MARS Local Controller 
P1210 78-17020-01 | 


CHAPTER 1 


Configuring Web Proxy Devices 


Web proxy devices provide MARS with additional data surrounding user requests of network services, 
such as HTTP, FTP, NNTP, and DNS. These device cache data and provide additional services around 
requests for that data. These additional services provide MARS with data about session requests, 
including authentication logs, denied session requests based on ACLs enforced by the web proxy device, 
and traffic logs. 


This chapter contains the following section: 


e Network Appliance NetCache Generic, page 13-1 


Network Appliance NetCache Generic 


This section contains the following topics: 
e Configure NetCache to Send Syslog to MARS, page 13-1 
e Add and Configure NetCache in MARS, page 13-2 


Configure NetCache to Send Syslog to MARS 


Synchronize clocks of the NetCache device and the MARS to make sure times match between them. 


MARS supports only HTTP proxy logs and MMS streaming media proxy logs. 


To configure NetCache to send syslog to MARS, follow these steps: 


In Internet Explorer, enter the URL and log in to the NetCache device. 
Click the Setup tab. 
In the left side of the window, select HTTP, then Logging. 


In the right side of the window, under Web Access Log Enable, select the Enable the Web Access Log 
checkbox. 


Under Log Format, select one of the first four formats: 
e Web Access Log Default Format 


¢ Common Log Format 
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Step 6 
Step7 
Step 8 
Step 9 


wy 


e Netscape Extended Format 

e Squid Type Format 
Under Web Details Log Enable, verify the box is not selected. 
Click Commit Changes to save your changes. 
In the left side of the window, select Streaming, then Logging. 


In the right side of the window, under Streaming Access Log Enable, select the Enables access logging 
for streaming protocol clients check box. 


Note 


Step 10 


Step 11 
Step 12 
Step 13 
Step 14 
Step 15 
Step 16 
Step 17 


Step 18 
Step 19 


Step 20 
Step 21 
Step 22 


Step 23 


You can only enable access logging for streaming protocol clients if you have a streaming cache license. 


Under Streaming Access Log Format, select either of the options. If you select Custom, replace 
“x-client-port” with “x-username”. 


Under Streaming Details Log Enable, verify that the box is not selected. 

Click Commit Changes to save your changes. 

In the left side of the window, select Streaming, then MMS. 

Under MMS Enable, verify that the Enables MMS protocol support check box is selected. 
Click Commit Changes to save your changes. 

In the left side of the window, select System, then Logging. 


In the right side of the window, under Maximum Log File Size, enter a number less than or equal to 100 
(megabytes). 


Under How to Switch Log Files, select Push the log file to the following URL. 
For the URL, enter: 


http: //MARS_HOST/upload/UploadWebLogServlet 


Replace MARS_HOST with the hostname or IP address of the MARS Appliance. 
Verify that the User and Password fields are blank. 
Verify that the Push the log files in compressed gzip format check box is not selected. 


Under When to Switch, select the option that prevents the log files from becoming greater than 100 
megabytes. 


Click Commit Changes to save your changes. 


Add and Configure NetCache in MARS 


Step 1 
Step 2 


To add the NetCache device in MARS, follow these steps: 


Select Admin > Security and Monitor Devices > Add. 


From the Device Type list, select Network Appliance NetCache Generic. 
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Step 3 
Step 4 


Step 5 
Step 6 


Network Appliance NetCache Generic 


Device Type:| Network Appliance NetCache Generic (v] 


> *Device Name: | 
> *Reporting IP: | a; | | 


> Web log format: 


COMMON_ACCESS_LOG 
SQUID_LOG 
NETSCAPE_EXTENDED_LOG 
NETCACHE_WEB_ACCESS_DEFAULT_LOG 


> Streaming media log format: 


Enter the device name and its reporting IP address. 


From the Web log format list, select the web log format that matches the value you selected in Step 5 of 


Configure NetCache to Send Syslog to MARS, page 13-1. 
From the Streaming media log format list, select a streaming media log format. 


Click Submit. 
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Configuring AAA Devices 


Authentication, authorization, and accounting (AAA) devices provide accountability throughout your 
network, ensuring that valid users are authorized to use the network services they request and providing 
detailed event logs regarding failures and successes in such requests. 


The AAA server is a key component in the Network Access Control (NAC) initiative (see Configuring 
Network Admission Control Features, page 2-42 and Enable NAC-specific Messages, page 3-4). Cisco 
Secure Access Control Server (ACS), which is the AAA server for NAC, returns access control decisions 
to the network access device on the basis of the antivirus credentials of the hosts that are requesting 
network services. 


MARS supports the Cisco Secure ACS software and the Cisco Secure ACS Solution Engine, version 3.3 
and later. In the case of Cisco Secure ACS software, support is provided by an agent that resides on the 
Cisco Secure ACS server. For the Cisco Secure ACS Solution Engine, this agent must reside on a remote 
logging host. This agent provides MARS with three event logs in syslog format. The logs are as follows: 


e Passed authentication log (requires Cisco Secure ACS, 3.3 or later) 
e Failed attempts log 
e RADIUS accounting log 


To support NAC and the 802.1x features, Cisco Secure ACS uses the RADIUS authentication protocol 
and the cisco-av-pair attributes. For more information on configuring Cisco Secure ACS as a posture 
validation server for NAC, see the following URL: 


http://www.cisco.com/en/US/products/sw/secursw/ps2086/products_user_guide_chapter09186a00 
802335f1.html 


For more information on the cisco-av-pair attributes, see the following URL: 


http://www.cisco.com/en/US/products/sw/secursw/ps2086/products_user_guide_chapter09186a00 
802335ea.html 


This chapter explains how to prepare the Cisco Secure ACS server or the Cisco Secure ACS Solution 
Engine to allow MARS to collect the event logs. It also describes how to configure MARS to receive and 
process these logs correctly. Using the web interface, you must define a host to represent the 

Cisco Secure ACS server (or the remote logging agent collecting logs for the Cisco Secure ACS Solution 
Engine) and then add the software application to that host. 
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Supporting Cisco Secure ACS Server 


To configure a Cisco Secure ACS server to act as a reporting device, you must perform three tasks: 


1. Configure Cisco Secure ACS server to generate the correct log files and details and define the AAA 
clients. 


2. Install the PN Log Agent on the Cisco Secure ACS server and configure it to forward the correct log 
files. 


3. Add the Cisco Secure ACS server to the MARS web interface 


You can also configure Cisco Secure ACS to provide command authorization for the MARS Appliance. 
In this role, Cisco Secure ACS verifies that the MARS Appliance is authorized to execute specific 
commands on reporting devices and mitigation devices. 


The following sections detail supporting a Cisco Secure ACS server: 
e Bootstrap Cisco Secure ACS, page 14-2 
e Install and Configure the PN Log Agent, page 14-7 
e Add and Configure the Cisco ACS Device in MARS, page 14-12 


Supporting Cisco Secure ACS Solution Engine 


MARS supports the Cisco Secure ACS Solution Engine via a remote logging host. Cisco Secure ACS 
Remote Agent for Windows and Cisco Secure ACS Remote Agent for Solaris are applications that 
support Cisco Secure ACS Solution Engine for remote logging. 


Even though the Cisco Secure ACS Solution Engine supports up to five appliance via a remote logging 
host, MARS currently supports only one Cisco Secure ACS Solution Engines per remote logging host. 
Otherwise, MARS cannot identify the IP address of the originating Cisco Secure ACS Solution Engine. 


To enable this support, follow these steps: 


1. Configure the Cisco Secure ACS Solution Engine to publish logs to the remote logging host. See 
Bootstrap Cisco Secure ACS, page 14-2. 


2. Install and configure either the Cisco Secure ACS Remote Agent for Windows and Cisco Secure 
ACS Remote Agent for Solaris on the target remote logging host. 


For instructions on installing and configuring the remote agent, see Installation and Configuration 
Guide for Cisco Secure ACS Remote Agents. 


3. Install the pnLog Agent on the remote logging host. 


For information on installing and configuring the pnLog Agent, see Install and Configure the PN 
Log Agent, page 14-7. 


4. Add the remote logging host to MARS as a Cisco ACS 3.x reporting device. To perform this task 
see Add and Configure the Cisco ACS Device in MARS, page 14-12, and substitute the ACS server 
references with the remote logging host. 


Bootstrap Cisco Secure ACS 


Bootstrapping the Cisco Secure ACS includes the following task: 
e Configure Cisco Secure ACS to Generate Logs, page 14-3 
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e Define AAA Clients, page 14-5 


Bootstrap Cisco Secure ACS 


e (Optional) Configure TACACS+ Command Authorization for Cisco Routers and Switches, page 


14-6 


Configure Cisco Secure ACS to Generate Logs 


To configure Cisco Secure ACS to generate the audit logs required by MARS, follow these steps: 


Step 1 Log in to the Cisco Secure ACS server or Solution Engine. 


Step2 Select System Configuration > Logging. 


Cisco Systems 


Ry | Shared Profile 


Components 


Interface 
Configuration 


Administration 
Control 


Be) External User 

Databases 

esas} Posture 

| ace}! Validation 
Network Access 

; Profiles 


& Reports and 
Activity 


Rial. 


System Configuration 


Logging Configuration 


Local Logging Configuration 


CSV Failed Attempts 


CSV Passed Authentications 
CSV RADIUS Accounting 


CSV TACACS+ Accounting 


CSV TACACS+ Administration 


CSV VoIP Accounting 


Cancel 
2 Back to Help | 


CS¥ Logs 

CS¥ Failed Attempts 

CS¥ Failed Attempts 

CS¥ RADIUS Accounting 
CS¥ TACACS+ Accounting 


CS¥ TACACS+ Administration 
CS¥ VoIP Accounting 

ODBC Logs 

ODBC Failed Attempts 

ODBC RADIUS Accounting 
ODBC TACACS+ Accounting 
ODBC TACACS+ Administration 
ODBC VoIP Accounting 
Remote Logging 


CS¥ Logs 


Cisco Secure ACS records many of its logs 
in comma-separated value (CSV) text 
files. You can import CS¥ log files into 
many popular spreadsheet applications, 


Back to Top zi 
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Step3 Verify that CVS Failed Attempts, CVS Passed Authentications and CVS RADIUS Accounting Logging 


are enabled. 


Step4 = Click CSV Failed Attempts, and verify that the following attributes appear in the Logged Attributes list: 


e User-Name 


e Caller-ID 
e NAS-Port 


e NAS-IP-Address 
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Cisco Systems 


i j 
. 


Bal | Sciue 


By | Shared Profile 


Components 


System Configuration 


CSV Failed Attempts File Configuration 


® Enable Logging 


Enable Logging 


M Log to CSV Failed Attempts report 


= -tm| Net work 
Wee | Configuration 


| Syster 
TS | Configuration 


nA 
My 
3 


Interface 
Configuration 


Administration 
Control 


ne) External User 
Databases 


Validation 


Network Access] 
Profiles 


& | Reports and 
Activity 


— 


Step 5 


Step 6 


(ae) | Online 


Documentation 


Click Submit 


Attributes list: 


Step 7 
Step 8 


User-Name 
Caller-ID 
NAS-Port 


Select Columns To Log i 


Attributes 


Logged Attributes 


UserName 

Group-Name 

Caller-ID 
Authen-Failure-Code 
Author Failure-Code h 


Priv-lvl 
Proxy-IP-Address 
ExtDB Info 
Source-NAS 

Filter Information 
Network Device Grot 
Access Device 


Device Command S = | 
PEAP/EAP-FAST-C 


Global Message Id | 
Logged Remotely 

EAP Type 

EAP Type Name 


Network Access Profi 
Outbound Class 


Shared RAC 
Doin ‘ 
Reset Colurnns Cancel 


Author-Data 
NAS-Port 
NAS-IP-Address 


Submit 


NAS-IP-Address 


System-Posture-Token 


EAP Type Name 


Click Submit. 
Click CVS RADIUS Accounting, and verify that the following attributes appear in the Logged 


Attributes list: 


Step9 To 


User-Name 


Calling-Station-Id 


Acct-Status-Type 


NAS-Port 


NAS-IP-Address 
support the 802.1x features of NAC, select the following RADIUS accounting attributes: 
Framed-IP address 


cisco-av-pair 


Select Columns to Log 
Log File Management 


Enable Logging 


This option enables you to change the 
layout of the log files that you can view 
under Reports and Activities, Select the 
Log to reportrame Report check box, and 
then configure the following parameters. 


Back to Top 


Select Columns to Log 


In the Attributes column, click the 
attribute to be logged and click -> to 
move it into the Logged Attributes 
column, Click Up or Down to move the 
column for this attribute to the desired 
position in the log, Repeat until all the 
desired attributes are in the desired 
position in the Logged Attributes colurmn, 


Back to Top 


Log File Management 


Click CVS Passed Authentications, and verify that the following attributes appear in the Logged 
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Bootstrap Cisco Secure ACS Hi 


CSV RADIUS Accounting File Configuration 


Enable Logging 
M Log to CSV RADIUS Accounting report 


Select Columns To Log 


Attributes Logged Attributes 


Framed-Protocol 
Login-IP-Host 
Login-Serice 


Calling-Station-Id 
Acct Status- Type 
Framed-IP-Address 


Class NAS-Port 
Termination-Action NAS-IP-Address 
cisco-av-pair 


Ee 


ls. 
> - J 
i=] 
o 
lF 
b 
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Step10 Click Submit. 


For additional details on the RADIUS attributes supported by Cisco Secure ACS, see to the following 
URL: 


http://www.cisco.com/en/US/products/sw/secursw/ps2086/products_user_guide_chapter09186a00 
802335ea.html 


Define AAA Clients 


To support the 802.1x features of NAC, you must also define the Cisco switches as AAA clients within 
Cisco Secure ACS. When defining a AAA client, verify the following settings: 


e RADIUS (IETF) is selected in the Using Authentication box, as other RADIUS implementations 
may not support 802.1x correctly. 


e The Log Update/Watchdog Packets from this AAA Client box is selected. 


Figure 14-1 displays the correct settings for such a client. 
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Figure 14-1 
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Configure a AAA Client to Support 802. 1x 


Network Configuration 


AAA Client Setup For 
802.1xrouter 


AAA Client 20.1.1.1 - 


TP Address x 


protego 


Key 


Authenticate 
Using 


Single Connect TACACS+ AAA Client (Record stop 
in accounting on failure). 


M Log Update/Watchdog Packets from this AAA Chent 


Log RADIUS Tunneling Packets from this AAA 
Chent 


Replace RADIUS Port info with Username from this 
AAA Chent 


Submit + Apply Delete 
Delete + Apply Cancel 


RADIUS (IETF) x 


r 


r 


AAA Client IP Address 

Key 

Network Device Group 

Authenticate Using 

Single Connect TACACS+ AAA Client 

Log Update/Watchdog Packets from this AAA Client 
Deleting a AAA Client 


Renaming a AAA Client 
Log RADIUS Tunneling Packets from this AAA 


Client 
Replace RADIUS Port info with Username from this 
AAA Client 


AAA Client IP Address 


Type the IP address information for this AAA 
client. 


If you want to designate more than one AAA client 
with a single AAA chent entry in Cisco Secure 
ACS, you can specify the IP address for each 
AAA client to be represented by this AAA chent 
entry. To separate each IP address, press Enter. 


You can use the wildcard asterisk (*) for an octet 
in the IP address. For example, if you want every 
AAA chent in your 192.168.13.1 Class C network 
to be represented by a single AAA client entry, 
enter 192.168.13.* in the AAA Chent IP Address 
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For more information on defining AAA clients, see the following URL: 


802335ef.html#wp342084 


http://www.cisco.com/en/US/products/sw/secursw/ps2086/products_user_guide_chapter09186a00 


Configure TACACS+ Command Authorization for Cisco Routers and Switches 


You can use the TACACS+ feature of Cisco Secure ACS to authorize the command sets that MARS is 

allowed to execute on a reporting device. The use of this feature is not required by MARS. However, if 
you are using this feature on your routers and switches, you must ensure that MARS is allowed to execute 
specific commands. Required commands are grouped under two operations: configuration retrieval and 
mitigation. 


The following commands support configuration retrieval: 


all show commands 


changeto system 


changeto context <context_name> 


enable 


page 


no page 


terminal length 0 
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e terminal pager lines 0 
¢ write terminal 
The following commands support mitigation: 
e conf terminal 
e interface <interface_name> 
e shutdown 
e set port disable <port_name> 


For more information on configuring command authorization sets in Cisco Secure ACS, see the 
following URL: 


http://www.cisco.com/en/US/products/sw/secursw/ps2086/products_user_guide_chapter09186a00 
802335ec.html#wp697557 


Install and Configure the PN Log Agent 


MARS includes the PN Log Agent to monitor Cisco Secure ACS active log files (failed attempts, passed 
authentications, and RADIUS accounting). This agent pushes these log files via syslog to MARS. You 
can download the PN Log Agent from the software download center at the following URL: 


http://www.cisco.com/cgi-bin/tablebuild.pl/cs-mars-misc 


wy 


Note _ If you are upgrading to a new version of the PN Log Agent, see Upgrade PN Log Agent to a Newer 
Version, page 14-9. 


As part of its operation, the PNLog Agent service writes error and informational message to the 
Application Log, which can be viewed using the Event Viewer. To learn more about these messages, see 
Application Log Messages for the PN Log Agent, page 14-10. 


To install and configure the PNLog Agent, follow these steps: 


Step 1 Download the PN Log Agent and install it on the server running Cisco Secure ACS or on the remote 
logging host to which the Cisco Secure ACS Solution Engine is publishing its logs. 


Note _[f installing on a remote logging host, you must have configured the Cisco Secure ACS Remote Agent 
for Windows and Cisco Secure ACS Remote Agent for Solaris on the target remote logging host. 


For instructions on installing and configuring the remote agent, see /nstallation and Configuration Guide 
for Cisco Secure ACS Remote Agents. 


Step2 Select Start > All Programs > Protego Networks > PNLogAgent > Pn Log Agent 
Step3) = Click Edit > PN-MARS Config. 
Result: The PN Log Agent Configuration dialog box appears. 
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PN Log Agent Configuration xi 


MARS IPAddess:| BH . 0.0. 0 


Syslog Port: [era 
coce_| 


148231 


Step4 In the MARS IP Address field, enter the address of the MARS Appliance, and click OK. 
Step5 Select Edit > Log File Config > Add. 
Step6 From the Edit pull down menu select Add. 

Result: The Add/Edit File Details dialog box appears. 


Add/ Edit File Details ; x| 


Application Name: [Cisco ACS - Failed Attempts x] 
Cisco ACS - Failed Attempts 


Loa File: Cisco ACS - Passed Authentications 
wees Cisco ACS - RADIUS Accounting 
Generic Application 


143230 


Step7 From the Application Name list, select the Cisco ACS-Failed Attempts. 


Step8 Click on the ... button to select the appropriate log where all Cisco Secure ACS logs are stored. In this 


example after selecting Failed Attempts application, be sure to select the matching log file, Failed 
Attempts active log. 


Result: The Open dialog box appears. 


A 
Look in: | (C9 Failed Attempts +] © © ex Fee 


#,|Failed Attempts 2005-06-11.csy 
#3)Failed Attempts 2005-06-12,csy 
Failed Attempts active.csy 


File name: [Failed Attempts active.csyv 
Files of type: CS¥ Files (* csv] ba Cancel | 


J Open as read-only y 
V; 
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Step9 Add all 3 applications and their active log files: 
e Failed Attempts active 


e Passed Authentications active 
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e RADIUS Accounting active 
Result: The configured files appear in the List of Log Files to Monitor list. 


"~'Protego Networks LogAgent aS oe 


File Edit Help 


List of Log Files to Monitor 


Application Name File Location 

Cisco ACS - Passed Authenticat... C:\Program Files\CiscoSequre ACS v3.3\Logs\Passed Authentications... 
Cisco ACS - RADIUS Accounting C:\Program Files\CiscoSecure ACS v3.3\Logs\RADIUS Accounting\RA... 
Cisco ACS - Failed Attempts C:\Program Files\CiscoSecure ACS v3, 3\Logs\Failed Attempts Failed... 
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Step10 Select File > Activate. 


Upgrade PN Log Agent to a Newer Version 


You can determine which version of the PN Log Agent is running on your server by selecting Help > 
About in the PN Log Agent Configuration dialog box. This program is updated independently of the 
MARS Appliance software updates. Therefore, the version number does not correspond to any release 
of the MARS Appliance software. 


Note Beginning with the 4.1.3 release of the pnLog agent, the agent requires a minimum of Cisco Security 
Monitoring, Analysis, and Response System, release 4.1.3 running on the appliances to which it is 
reporting in order to operate correctly. 


To upgrade to the new PN Log Agent from an existing installation, you must perform the following steps: 


Step 1 On the Cisco Secure ACS or syslog server where PN Log Agent is running, uninstall the old agent. 
a. To uninstall the old agent, click Start > Control Panel > Add/Remove Programs. 
b. Select PnLogAgent in the list of currently installed programs, and click Remove. 
c. Select Yes to confirm the removal. 

Step2 Reboot the server. 

Step3 —_— Install the new agent. You can download this tool from the following URL: 


http://www.cisco.com/cgi-bin/tablebuild.pl/cs-mars-misc 
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Step4 Re-configure the new agent, specifying the list of files and IP address of the MARS Appliance, etc. 


For information on configuring the pnLog Agent, see Install and Configure the PN Log Agent, page 
14-7. 


Application Log Messages for the PN Log Agent 


The PN Log Agent service writes events to the Application Log of Event Viewer on the Cisco Secure 
ACS server. The agent, identified in the log messages as PNLogAgentService, writes status messages, 
such as successful service start and stop. It also writes error messages for incomplete configuration and 
error conditions, such as when the service is out of memory. 


Table 14-1 categories the types of messages that can occur and explains their affects on the PNLog Agent 
service. 
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Table 14-1 Possible Application Log Messages for PN Log Agent 


Type/Message Effect on Service/Cause of Error 


Fatal Errors 


Failed to start thread to monitor file. Windows errors or configuration errors that will stop 
the service 


The service failed to monitor the configured file. Please check 
service privileges. 


The service failed to obtain path from log file name and shall exit 
the thread now! 


The service failed to get the CS-MARS device IP Address. Please 
use the PnLogAgent to configure it. 


The service has detected an invalid IP address. Please use the 
PnLogAgent to configure the correct IP Address for CS-MARS. 


Error 
Network detected to be down while attempting to send syslog Network connectivity errors that will cause the service 
message to not send syslog messages, but will keep the service 


Destination network unreachable while attempting to send syslog ee 


message 


Network dropped connection on reset condition while attempting to 
send syslog message 


Connection reset by peer while attempting to send syslog message 


Connection refused by target while attempting to send syslog 
message 


No route exists to host. Please check the network connectivity 


Attempt to send syslog returned error code: <error_code> 


The log file doesn't have all required attributes. Attribute missing: |Error in configuration 
<missing_attribute> 


The number of attributes in the file header don't match the number 
of attributes in the value. Hence this log entry shall not be sent to 
CS-MARS. 


The service detected that the configured file is missing some 
mandatory header attributes. A list of mandatory attributes is 
available in the CS-MARS user documentation. 


The service failed to read the file pnWinEvent.dat and will now wait 
for an update to the configuration. 


Failure in reading from pnWiinEvent.dat. Service will wait for an 
update 


Warning 


The attribute <attribute_name> has a value that exceeds the Warning in case some attribute data in the file exceeds 
CS-MARS limit for an individual attribute value and shall be split. |MARS raw message length... MARS will store the data 
after splitting it into multiple events 


Informational 
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Table 14-1 Possible Application Log Messages for PN Log Agent (continued) 
Type/Message Effect on Service/Cause of Error 
PnLogAgentService started Informational messages describing expected operations 


PnLogAgentService Exiting for the service. 


The service read the configuration and will attempt to process files. 


As the service has no logs configured, it shall wait for an update 


Exiting thread processing file as service stop received! 


Add and Configure the Cisco ACS Device in MARS 


To add the host and Cisco Secure ACS software application to MARS, follow these steps: 


Step1 Click Admin > Security and Monitor Devices > Add. 
Step2 From the Device Type list, select Add SW Security apps on a new host. 


You can also select Add SW Security apps on an existing host if you have already defined the host within 
MARS, perhaps as part of the Management >IP Management settings or if you are running another 
application on the host, such as Microsoft Internet Information Services. 


Step3 In the Device Name field, enter the hostname of the server or the remote logging host. 


Step4 In the Reporting IP field, enter the IP address of the interface in Cisco Secure ACS server or the remote 
logging host from which the syslog messages will originate. 


Step 5 Under Enter interface information, enter the interface name, IP address, and netmask value of the 
interface in Cisco Secure ACS server or remote logging host from which the syslog messages will 
originate. 


This address is the same value as the Reporting IP address. 
Step6 Click Apply. 
Step7 Click Next to move the Reporting Applications tab. 
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Step 8 


Add and Configure the Cisco ACS Device in MARS Ti 


g 
| General __| Reporting Applications 


Enter reporting application: 


> Device Name: Softie II 


> Select application: | : 


Edit Remove 
i Device Type 


In the Select Application box, select Cisco ACS 3.x, and then click Add. 


Result: The Cisco ACS 3.x Windows Requirements page appears, explaining that you must have 
installed an agent on the server as described in Install and Configure the PN Log Agent, page 14-7. 


Step 9 


Step 10 


Step 11 


Step 12 


The Cisco ACS 3.x option supports both Cisco Secure ACS 3.x and Cisco Secure ACS 4.0. No explicit 
4.0 option exists for Cisco Secure ACS. 


Click Submit to add this application to the host. 
Result: Cisco ACS 3.x appears in the Device Type list. 


Click the Vulnerability Assessment Info link to define the host information that MARS uses to 
determine false positive attacks against this host. Continue with Define Vulnerability Assessment 


Information, page 10-11. 
Click Done to save the changes. 
Result: The new host appears in the Security and Monitoring Information list. 


To activate the device, click Activate. 
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Adding User Defined Log Parser Templates 


MARS allows the user to enter any SYSLOG or SNMP device into the network topology, configure it to 
report data to the MARS and query the data using free-form query. 


User needs to specify the incoming data format so that MARS can parse and retrieve session information 
from arbitrary logs. 


In order to add a user defined log parser template, the following steps have to be taken: 


Step 1 Add a custom Device or Application type 
Step2. Add a log parser template 
Step3 Add device with the above custom Device or Application type. 


To add a custom Device/Application type: 


Step1 Go to Admin >Custom Setup tab 
Step2 Click the User Defined Log Parser Templates 
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Figure 15-1 User Defined Log Parser Template 


SUMMARY || INCIDENTS || QUERY 
: #s |[ Custom setup | 


BR ADMIN | PN-MARS Standalone: pnmars34 v3.3 Login: 


User Defined Log Parser Templates 


Device/Application Type: [None available a [ada ][ edit |[ delete | 


Log Templates 


|Log ID Log Description Mapped to Event Type 
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Step3 On the next screen, click Add button which is located next to the Device/Application type list 


Figure 15-2 Device Type Definition 


[somnaee J weve [ 
[System Setup || System Maintenance |[ User Management || System Parameters || Custom Se 


§P\ ADMIN | PN-MARS Standalone: pnmars34 v3.3 


Device/ Application Type Definition 


*Type: @ Appliance @ Software 


"vendor: 


*Model: Model1 
*Version: 
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Step4 | Choose the Type - Appliance or Software. 
e Appliance - A hardware device that can send logs to the MARS Appliance 


e Software - An application running on a host and the host can be configured to send logs to the 
MARS Appliance 


Step5 Enter the Vendor, Model and Version for the Device or Application. (For Example, Cisco PIX 7.0) 
Step6 Click Submit. 
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Figure 15-3 User Defined Device/Application Type 


User Defined Log Parser Templates 


Device/Application Type: | Vendori Modeli 1.2 


Log Templates for : Vendori Modell 1.2 


Add || Edit Delete 


Log ID Log Description Mapped to Event Type Severity 


Oto 0 of 0 


Add || Edit Delete 


25 per page 
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To add Parser Templates for a Device/Application 


Step1 Go to the Admin > Custom Setup tab. 
Step2 Click the User Defined Log Parser Templates. 
Step3 Select the newly created/existing Device or Application from the dropdown. 
Step4 To add a log template, click Add which located in the Log Template area. 
A log template ties directly to the particular message that you want to parse. A log template is composed 
of one or more Event Types that describe the contents of the message. Using the Event Types, MARS 
parses the message when it is received. 
Step5 Enter Log ID - a tag that will identify the log message. 
The Log ID field provides an opportunity to map this message number or another moniker used by the 
device to the custom event type that you are developing. You can use this value to clarify the device 
messages for which you have developed custom event types. 
Step6 Enter Description - a description of the log message. 
Step7 Map the log to an Event Type. 
% 
Note The MARS Appliance comes with a number of predefined Event Types. To display them, select System 
(for example) from the list above the Event Type select window and click Get) 
Step8 § New Event Types can be added by clicking Add below the Event Type list. 
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Figure 15-4 Mapping Log to Event Type 


Log Template for : Vendor1 Modell 1.2 


gy 
Definition Patterns 
> *Log ID: Logi 
> Description: The first example log message to parse 


Map to Event Type 


> *Event Type: 


Teardown Connection C Teardown Connection 


Figure 15-5 Define Event Type 


Event Type Definition 


*Event Type: [TEARCONN 


Description: = |Teardown Connection 


Severity: [RED x] 


Step9 Add new Event type and its information and click Submit (optional) 
Step10 Click Apply - the Patterns link will become enabled. 
Step11 Click the Patterns link. 
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Step 12 


Step 13 
Step 14 


Step 15 
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Figure 15-6 Define Event Patterns 


Patterns for Log Template : Logi 
g 


Definition [ attterns 


Add || Edit Delete Test 


Position Key Pattern Parsed Field ¥alue Type Yalue Format Yalue Pattern 


0 to O of 0/25 per page 


Add | Edit | Delete | Test 
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| 2 Back | | Submit | 


Click Add to input patterns. 


The parsing patterns for the example above are specified to match the following example raw message 
reported in an event. 


Teardown TCP connection 1000 faddr 67.126.151.132/80 gaddr 198.133.219.28/43246 laddr 
10.1.1.30/890 (sudha) duration 01:00:02 bytes 1000000 (TCP FINs) 


The first step is to identify the values in the log that need to be parsed and stored in MARS events. 
Currently MARS supports the following parsed value fields in its events: 

e Source address 

e Destination address 

e Source port 

e Destination Port 

e Protocol 

e NAT Source address 

e NAT Destination address 

e NAT Source port 

e NAT Destination Port 

e NAT Protocol 

e Device Time stamp 

e Session Duration 

e Received Time stamp 

e Exchanged Bytes 

e Reported User 


The parsing format can now be thought of as being made up of several KEY pattern followed by VALUE 
patterns. Both KEY and VALUE patterns are regular expressions based on the library PCRE which is 
perl-compatible regular expressions (Appendix B, “Regular Expression Reference.” for details on 
syntax). Note that a KEY can be an empty string. A log format consists of several KEY- VALUE 
sub-pattern pairs. 
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Step 16 


Step 17 


Step 18 


Step 19 


Step 20 


Figure 15-7 Define Pattern for a Log 


Pattern definition for Log ID : Logi 


Key Pattern: [Teardown 


Parsed Field: | protocol 


¥alue Type: Protocol (String) 


Pattern Name:| ppotoc OL_STRING 


Description: Protocol, as a protocol 


string as defined 
in /etc/protocols 


¥alue Pattern: |[\w-/+]+ 
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@ Cancel Submit 


In the above example, the Position refers to the position of each KEY-VALUE sub-pattern pair. These 
KEY-VALUE sub-pattern pairs are concatenated in the order of their positions and used for matching 
against the raw message in an event. It does allow arbitrary whitespace between KEY and VALUE 
patterns, as well as between KEY-VALUE sub-patterns. 


In the above example, the Key-Pattern is “Teardown’” is a simple regular expression that does not have 
any wildcards or repetitions. 


The Parsed Field is one of fields of a MARS event that has been fully parsed. In the above case, it is the 
protocol field. 


The Value Type gives indication to the parser on what kind of value to expect so that suitable parsing 
action can be applied on the matching sub-pattern string. By “Choosing Protocol (String)” as the value 
type above, we indicate that the protocol field is coming in the form of a string as defined in the file 
/etc/protocols in a UNIX system. For example, “TCP” is the string that will be captured by the value 
pattern. The Value Type will indicate that TCP is to be converted into its protocol number, 6. 


Pattern Name is a mnemonic given to standard regular expression patterns available for the user who is 
specifying the log format. There are several common pre defined patterns with appropriate names. In the 
edit box right below the Pattern Name list, a user can add new value names to identify value patterns 
that may be commonly used in their logs. In the above figure, the value pattern captures all 
word-character strings that may also include the characters ‘-*, ‘/’ and ‘+’. 
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Step 21 


Step 22 


Step 23 


Figure 15-8 Sub Pattern Definition 


Pattern definition for Log ID : Log1 


=> Position: 


connection [+-]?\d+ faddr 


=> Key Pattern: 
> Parsed Field: 


Source Address 


> ¥alue Type: 


IPV4 (Dotted Quad) ¥ 


—> Pattern Name: IP¥4_DOTQUAD 


> Description: 


IPV4 Address, Dotted Quad 


> Value Pattern: [([o1)?\d\d?/2[0-4]\d/25[0-5))\. {3 (01175 


Adding User Defined Log Parser Templates Hi 


143250 


© Cancel Submit 


The above KEY- VALUE sub-pattern in the 2" position of the log format. Notice that the key pattern isn’t 
just a simple string, it is a regexp \d+ which matches against all unsigned decimal numbers. The parsed 
field where the above value is stored is the Source Address which is specified as a dotted quad. Notice 
the somewhat complicated regexp that only capture IP addresses in the correct range (0.0.0.0 through 


255.255.255.255). 


Figure 15-9 


Pattern definition for Log ID : Logi 


Third Position of Pattern Definition 


> Position: 


> Key Pattern: |, 


> Parsed Field: 


Source Port 


> Value Type: 


Port (Number) + 


> Pattern Name:|/porT_NUMBER 


=> Description: 


prefixed with Ox 


Port, as an Unsigned 5 digit - 
Decimal or 4 digit Hex Number 


a 


> Yalue Pattern: |((ox[a-fa-Fid]{1,4})1(\d{1,5})) 


143251 


© Cancel Submit 


The above is for a source port. PORT_NUMBER is the Pattern Name, provided for the above Value 


Pattern with the Description above. 


Repeat for every position of Pattern definition. 
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Figure 15-10 


The above example is a 12 KEY-VALUE sub-pattern pieces. 


Patterns for Log Template : Logi 


Definition 


Patterns 


il 


2 


3 


4 


5 


ORWVORP ORR ORD ORY ORY 
~~ 


Figure 15-11 


Teardown 


connection [+-]? 
\d+ faddr 


/ 
gaddr 


laddr 


NQ(\E 
\Qduration\E 


bytes 


Protocol 


Source Address 


Source Port 


Destination 
Address 


Destination Port 


NAT Dest Address 


NAT Dest Port 
Reported User 
Session Duration 
Session Duration 


Session Duration 


Bike Key Pattern Parsed Field ¥alue Type 


Protocol String 


IPV4 Dotted 
Quad 


Port Number 


IP¥4 Dotted 
Quad 


Port Number 


IP¥4 Dotted 
Quad 


Port Number 
String 
Duration-Hours 
Duration-Minutes 


Duration- 
Seconds 


Transmitted Bytes Number 


Add || Edit || Delete Test 
alue ¥alue Pattern 
Format 


[\w-/+]+ 


(((01]?\d\d? | 2[0-4 ]\d|25[0-5))\.)13} (01) ?\d\d?|2[0-4] 
\d|25[0-5]) 


((Ox[a-fA-F\d)}{1,4})|(\d{1,5})) 


((LOL]\d\d?|2[0-4]\d|25[0-5])\.){3}([O1] \d\d? |2[0-4] 
\d|25[0-5]) 


((Ox[a-fA-F\d){1,4})|(\d{1,5})) 


((LOLJ\d\d? |2[0-4]\d|25[0-5])\.)£3}([01]?\d\d? |2[0-4] 
\d|25[0-5]) 


((OxLa-fA-F\d){1,4})1(\d{1,5})) 
\w+ 

(Ox)?[a-fA-F\d 
(Ox)?[a-fa-Fyd]+ 


+ 


5 


(Ox)?La-fa-F\d 


(Ox)?[a-fA-FAd]+ 
1 to 12 of 12[2s per page = 
Add || Edit || Delete Test 


.. f 
ise] 


Log template for the device type ‘Vendor1 Model 1.2: 


User Defined Log Parser Templates 


Device/Application Type: [vendort Modeli 1.2 =[ada || edit |[ vetete | 


Log Templates for : Vendor1 Modeli 1.2 


| | Log ID_|Log Description Mapped to Event Type [Severity | 


The first example log message to parse 


Cc Logi 


Teardown Connection|[a] Xx] 


1 to 1 of [25 per page =] 


143236 


m User Guide for Cisco Security MARS Local Controller 


78-17020-01 | 


| Chapter 15 


Configuring Custom Devices 


Figure 15-12 
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New software based Apache Webserver application. 


Device/ Application Type Definition 


*Type: 
*¥endor: 
*Model: 


*¥ersion: 


Figure 15-13 


c Appliance @ Software 


Apache 


Sample Definition for Apache Webserver1.1 


Log Template for : Apache Webserver 1.1 


2 SA ler ype 


=> Description: 


HTTP Status - 


Map to Event Type 


> *Event Type: 


OK 


% 


HTTP Status OK 


HTTP Status 200 (OK} log 


a 

o 

NN 

2 
Patterns 


4ll Severity 


on eo Tele Tee ce Kel ce Kel oe 


HTTP Status - Accepted 


HTTP Status - Bad Gateway 
HTTP Status - Bad Request 
HTTP Status - Conflict 

HTTP Status - Continue 

HTTP Status - Created 

HTTP Status - Expectation Failed 
HTTP Status - Forbidden 

HTTP Status - Found 


HTTP Status - Gateway Timeout 


LITER Pande ane 


[a] 
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Step 24 Define the log template for a HTTP Status OK log message. And associate a system defined event type. 
In order to find the event type, specify the search string ‘HTTP Status’ and find it defined as above. 


Step25 The parsing patterns for “HTTP Status OK’ are specified to match the following example raw message 


reported in an event. 


155.98.65.40 - 


[21/Nov/2004:21:08:47 


"Lynx/2.8.2rel.1 libwww-FM/2.14" 


-0800] 


"GET /~shash/ HTTP/1.0" 


200 1633 
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Step 26 


Step 27 


Figure 15-14 Key Pattern for HTTP Status OK 


Pattern definition for Log ID : HTTP Status OK 


> Position: 
Key Pattern: 


Parsed Field: | Source Address 


¥alue Type: [| py4 (Dotted Quad) |» 


Pattern Name:|[py4 DOTQUAD |» 


Or enter new: 


Description: |tpyq address, Dotted Quad 


¥alue Pattern: [/([(91J?\d\d?|2[0-4]\d|25[0-5)\. {3} ([01]?4 


© Cancel Submit 


143239 


The key pattern is empty above since the log message starts with a value pattern. 


Figure 15-15 Position 2 Key Pattern for HTTP Status OK 


Pattern definition for Log ID : HTTP Status OK 


> Position: 


=> Key Pattern: No- - [XE 


> Parsed Field: [Received Time 


> ¥alue Type: [Time =] 


> Pattern Name:|pp/mMON/YYYY:HH:MI:SS TZ 


> Description: 


Time, Format example: 
05/0ct/2004:13:08:47 -0700 


© Cancel Submit 


143240 


The Parsed Field above is a Date/Time field. In addition to Value Pattern, a value format is required 
since a date/time can be specified in arbitrarily different ways. Details on how to specify the value format 
are given in Appendix F. Several pattern names with a few of the commonly used date/time formats have 


been predefined. 
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Figure 15-16 Position 3 Key Pattern for HTTP Status OK 


Pattern definition for Log ID : HTTP Status OK 


> Position: 
Key Pattern: fy \"((oyyy*ny*)*\" 200 


Parsed Field: [Transmitted Bytes 


Value Type: [Unsigned Number | 


Pattern Name:|TpaNs_BYTES_NUMBER =] 


Description: [Transferred Bytes, as an 
Unsigned Decimal or Octal 
with prefix 0 or Hex Number = ¥| 


¥alue Pattern: |(9x)?[a-fa-Fid]+ 
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Figure 15-17 Pattern log for HTTP Status OK 


Patterns for Log Template : HTTP Status OK 
% 


Definition Patterns 


Add || Edit || Delete Test 


Position|Key Pattern Parsed Field |¥alue Type |¥alue Format ¥alue Pattern 
ei! Source Address IPV4 Dotted (([O1J?\d\d?|2[0-4]\d|25[0-5))\.){3}((01]? 
Quad \d\d?|2[0-4]\d|25[0-5]) 
O 2 \Q- - [KE Received Time Time Yod/Yobs/YoY:%oHi% \d{1,2}Aw+Ad{4}i\d{1,2}:\d{1,2} vd 
Mi %S%z {1,2} [+-]\d{4} 
c 3 ND NCICN AFG") Transmitted Number (Ox)?[a-fa-FA\d]+ 
*\" 200 Bytes 


1 to 3 of 3[25 per page x] 
Add || Edit Delete Test 


< Back Submit 
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Figure 15-18 User Defined Log Parser for Apache Webserver1.1 


User Defined Log Parser Templates 


Device/ Application Type: 


Apache Webserver 1.1 ¥ 


Log Templates for : Apache Webserver 1.1 


BS Log ID Log Description Mapped to Event Type [Severity | 
C HTTP Status OK HTTP Status 200 (OK) log HTTP Status - ok [a] A) 


1 to 1 of 1 25 per page =] 
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Adding the new custom device or application is similar as adding predefined device or application. 


Below is the example of adding the newly user created Apache Webserver1.1: 


Step 1 Go to the Admin tab. 

Step2 Click the Security and Monitor Devices . 

Step3 Click Add to add a new device. 

Step4 From the Device Type list, select Add SW security apps on a new host. 
Step5 —- Fill in name and other host details and click Apply. 

Step6 Click on Reporting Applications.. 

Step7 Select Application (e.g., Apache Webserver.1.1) from the list and click Add. 


Figure 15-19 Adding the Customer Application to MARS 


Device Type: Edit host with security applications 


% 
| General | Reporting Applications ¥ulnerability Assessment Info 


Enter reporting application: 


> Device Name: Hostl 


> Select application: | apache Webserver 1.1 


Remove 


eal Device Type 


[” Apache Webserver 1.1 
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Step8 Select Reporting Method (SNMP TRAP or SYSLOG) on the resulting window and click Submit. 
Step9 Click Done. 
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Policy Table Lookup on Cisco Security Manager 


MARS and Cisco Security Manager (Security Manager) can be configured to provide round-trip policy 
audit features and improve traffic flow analysis and debugging. Using this feature, you can identify the 
ACL on a router or firewall that generated a syslog message received by MARS. It is important to 
understand that the integration between MARS and Security Manager is unique; MARS can provide 
users of Security Manager with better analytical tools. 


When using MARS as your STM solution, you must understand that MARS suggests and makes changes 
to devices without notifying Security Manager of the suggested changes. Specifically, you can use the 
“Big Red” button to shutdown a port for support L2 devices. For a layer 3 device, MARS suggest ACL 
changes to block the traffic. In such cases, you can use Security Manager to manually mitigate using the 
ACL recommendations provided by MARS, thereby, ensuring that the configuration management 
solution stays abreast of the mitigation responses. Security Manager can also publish the same change 
to all like devices that it manages, providing a more robust containment. 


For example, consider the following case where a user cannot connect to destination X from source Y. 
To troubleshoot this issue, an administrator can do the following: 


1. Log into the MARS web interface, and using an on-demand query, determine whether an event has 
been received that shows that traffic from source Y to destination X has been blocked. 


2. If such events are found, the administrator can continue by determining which ACL is actually 
blocking the traffic. To do so, the administrator would click the policy query icon in the row of one 
of the selected events. MARS then queries Security Manager to retrieve the list of ACLs that match 
that traffic flow, and assuming Security Manager was used to configure the routers and firewalls 
between source Y and destination X, then a list of matching ACLs are returned. 


3. Next, the administrator can log into the Security Manager user interface and modify the identified 
policy, or ACL, to allow traffic between source Y and destination X. 


This chapter describes how to configure Security Manager and MARS to ensure optimal functionality 
and seamless integration. 


Overview of Cisco Security Manager Policy Table Lookup 


When MARS receives a syslog from a Cisco PIX firewall, Cisco Adaptive Security Appliance (Cisco 
ASA), Cisco Firewall Services Module (Cisco FWSM), or Cisco IOS, and can derive the five tuple 
information required to establish an event (source IP, destination IP, source port, destination port, and 
protocol) the Security Manager Policy Table Lookup icon appears in the Reporting Device column 
of the MARS session display. Clicking the icon invokes a query to the Security Manager, the result of 
which is to identify the access rule in the policy table of the device which created the traffic incident or 
event. Figure 16-1 depicts the policy query process between MARS and Security Manager. 
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Figure 16-1 


Select one device. -—>| 


Click the 
Policy Table 
Lookup icon. 


! 


MARS authenticates to Security 


Cisco Security MARS Policy Table Query Process 


Manager with the Security Manager 
Username and Password. 


Success 


MARS requests the device ID from 
Security Manager by providing the 


hostname and IP address. 
If obtainable, MARS provides the 
domain name, and device type. 


MARS displays all 
matching devices. 


Multiple Number 


of matching 
devices 


One 


MARS requests from Security 
Manager all access rules that 
match the device ID and five tuples. 
If available, MARS provides action, 
ACL name, interface, and 
direction information. 


| Success 


MARS displays the Policy Lookup 
table for the device and highlights 
the matching access rules. 


Failed 
Error MARS displays an 
error message ina 
pop-up window. 
None 

Error 
v 
End 
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Overview of Cisco Security Manager Policy Table Lookup Hl 


The syslog that generated the MARS incident or event may not have sufficient information for Security 
Manager to uniquely identify the device or the access rule. In these ambiguous cases, Security Manager 
returns a list of all possible devices to MARS in a pop-up window. When the MARS user manually 
selects a reporting device, the policy table is then displayed for that device. Access rules that match the 
query criteria are highlighted. 


Note 


The policy table displayed by MARS is the Security Manager Committed View, not the Deployed View, 
meaning the displayed Security Manager policies are saved in the Security Manager database but not yet 
deployed on the device. If the deployed and committed views are not identical, the access rule generating 
the MARS event may not be visible in the policy table displayed by MARS. For further information on 
Cisco Security Manager operation, please access the documentation at the following URL: 
http://www.cisco.com/en/US/products/ps6498/tsd_products_support_series_home.html 


More About Cisco Security Manager Device Lookup 


MARS requests the Policy Table of a Security Manager device by supplying the following criteria to 
Security Manager: 


e Device Name—Derived from MARS Device Name 
e IP Address—Derived from MARS Reporting IP 


e Domain Name—TIf available, derived from the device name in MARS (for example, 
c3550-225-125.clab.cisco.com) 


e Device Type—If available from MARS 
The Device Lookup query includes the following actions between MARS and Security Manager: 


1. Security Manager matches the MARS Device Name to the Security Manager host names. If only one 
matching host name is discovered, the process for Policy Table Lookup is invoked. 


2. If the Security Manager host name is undefined, then Security Manager matches the MARS 
Device Name with the Security Manager Display Name (display names are unique, but the host 
name may be a substring of many display names.) 


3. If there are multiple matches on host name and no unique display name matches, the domain name 
(if available) is used to narrow the choices. 


4. Ifthe domain name is not available, MARS Reporting IP is used to narrow the choices. 


5. Ifaunique device cannot be identified, MARS displays a list of possible devices in a pop-up window 
that shows the IP address, host name, display name, and domain name for all possible device 
matches. The user manually selects the device and the process for the policy table lookup is invoked. 
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More About Cisco Security Manager Policy Table Lookup 


The device lookup information is combined with the event information to perform the Security Manager 
policy table lookup. 


The following MARS event information derived from the reporting device raw message is passed to 
Security Manager: 


e Event Five Tuple—Source IP Address, Destination IP address, Source Port, Destination Port, and 
Protocol defining session. The event five tuple must match the five tuples of the target access rule. 
For ICMP logs, ICMP type and code, when available, are passed instead of the source and 
destination ports. 


e Action—If available, permit or deny. If not available, access rules with both permit and deny are 
highlighted. 


e ACL name—TIf available, the name of the ACL or Access Group that triggers the syslog. With the 
ACL name, Security Manager can reduce the number of matching access rules. 


e Interface—lIf available, the interface names are parsed from the event’s raw message. 
e Direction—If available, keyword such as “inbound” and “outbound” identify the direction. 


The device, five tuple, action, ACL name, interface, and direction information comprise the policy query 
criteria submitted to the Security Manager. MARS displays the policy table in a pop-up window. The 
matching access rule is displayed in highlight. If MARS was unable to provide the interface, direction, 
and action information, multiple matched access rules may be highlighted. 


Sample Cisco PIX Firewall Syslog Messages with Direction and Protocol Information 


10.33.10.2 <142>%PIX-6-302013: Built outbound TCP connection 2021 for 
inside:10.1.1.10/4000 (10.1.1.10/4000) to dmz:192.168.1.10/80 (192.168.1.10/80) 


10.33.10.2 <142>%PIX-6-302013: Built inbound TCP connection 2000 for 
outside:1.234.58.149/12000 (1.234.58.149/12000) to inside:192.168.1.10/25 (100.1.4.10/25) 


Sample Cisco PIX Firewall Syslog Messages with Access Group Name Information 


10.33.10.2 <142>%PIxX-4-106023: Deny tcp sre inside:10.1.5.234/3010 dst outside:5.6.7.8/21 
by access-group "Cisco Security Manager-acl-inside" 


Sample Cisco 10S 12.2 Syslog Messages with ACL Name Information 


100.1.20.2 Mon Jun 9 14:46:31 2003 <46>485232: Jun 9 14:46:29 PDT: *SEC-6-IPACCESSLOGP: 
list Cisco Security Manager-acl-FastEthernet0/0 permitted tcp 1.234.51.255(12000) -> 
100.1.4.10(25), 1540 packet 


10.34.1.1 <46>146570: Dec 19 21:01:57 PST: %SEC-6-IPACCESSLOGP: list Cisco Security 
Manager-acl-FastEthernet1/0 denied tcp 10.10.1.20(59399) -> 10.1.5.11(23), 1 packet 


Prerequisites for Policy Table Lookup 


¢ MARS Local Controller running software version 4.2.1 or more recent version. 
¢ Cisco Security Manager version 3.0.1 or more recent 


e MARS configured for operation with Cisco Security Manager as explained in the section, Checklist 
for Security Manager-to-MARS Integration, page 16-6 


User Guide for Cisco Security MARS Local Controller 
mies 78-17020-01 | 


| Chapter 16 


Policy Table Lookup on Cisco Security Manager 


Overview of Cisco Security Manager Policy Table Lookup Ml 


Restrictions for Policy Table Lookup 
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A Local Controller can be configured to retrieve the policy tables from only one 
Cisco Security Manager server at a time. 


The Policy Table Lookup icon in MARS is displayed only for traffic logs which are reported by the 
following MARS device types: 


- Cisco Switch-IOS 

- Cisco PIX firewalls 

- Cisco Adaptive Security Appliance (Cisco ASA) 
- Cisco Firewall Services Module (Cisco FWSM) 


MARS displays the Cisco Security Manager security policy committed views, not the deployed 
views. The access rule causing the MARS event may not be visible in the policy table. To examine 
the deployed policies view of a device, you must login to the device or Cisco Security Manager 
directly. 


MARS examines only Layer 3 ACLs for traffic events on the supported reporting devices. The policy 
table lookup cannot directly indicate the cause of a traffic event caused by a deny not related to the 
displayed access rules, though the policy table can be displayed for the event (For instance, a no 
route deny, or a Network Address Translation [NAT] deny due to a NAT misconfiguration). 


The Security Manager Policy Table Lookup icon displays only for those events with 5-tuple event 
data (source and destination address, protocol, source and destination port). In the MARS web 
interface, the all matching events query diplays the text “session five tuple” for events with no 
5-tuple event data. These events will not have a policy query icon. 


The Security Manager Policy Table Lookup icon displays for NetFlow events even though they are 
not triggered by an ACL. This extra event data allows you to determine whether there is a policy 
permitting that traffic, which ensures you are able to tune accordingly. 


Note 


Because this is NetFlow data, it may not match the exact ACL or match multiple ACLs. 


The same events received by MARS can display the Security Manager Policy Table Lookup icon 
inconsistently between the low-latency, real-time event query and standard queries, such as sessions 
ranked by time. Specifically, the icon will not appear in the low-latency, real-time query, but it may 
appear in queries against sessionized events. 


This behavior is expected. When MARS receives events, they are parsed, sessionized, written to an 
event shared buffer, and then written to the database. Because sessionization takes time, sometimes 
keeping an event in cache for 2 minutes, the low-latency event query displays events right after 
parsing, but before sessionization. Displaying the event at this point allows the low-latency query to 
achieve a close to real-time effect. For some events, parsing cannot determine some part of the 
5-tuple data, such as a destination address. Later, sessionization later fills in such missing data using 
configuration data. As a result, the 5-tuple data displayed by the low-latency event query can be 
different from values stored in the database, which are used to populate the standard queries. 


An etror can occur with the policy query if a device configuration is discovered using Security 
Manager but it is not submited in Security Manager. The following error message is an example of 
this issue: 


<190>2312080: *May 9 23:50:02.199: %SEC-6-IPACCESSLOGDP: list permit-all permitted 
icmp 10.2.3.8 -> 10.4.21.2 (0/0), 1 packet 
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An error occurred while querying policies from Cisco Security Manager. Reason: 
Failed to retrieve policy information from CSM. Reason: Cisco Security Manager 
Internal error: Failed to get interfaces in the device! 

The device LC2DTM was discovered by CSM without any errors. 


Before you perform policy queries, verify that all discovered devices have been submitted in 
Security Manager. 


Checklist for Security Manager-to-MARS Integration 


Security Manager-to-MARS integration deals with identifying the required and optional points of 
integration, configuring the applications and devices, and ensuring proper authorization among the two 
management platforms. This checklist assumes a greenfield install of both Security Manager and MARS. 


The following checklist describes the tasks required to understand the decision-making process and the 
basic flow required to integrate MARS with a Security Manager server and the reporting and mitigation 
devices managed by that Security Manager server. Each step might contain several substeps; the steps 
and substeps should be performed in order. The checklist contains references to the specific procedures 
used to perform each task. 


Note For a comprehensive checklist on configuring MARS to operate most effectively as an STM, see 
STM Task Flow Overview, page 1-1. 
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Y/Y |Task 


1. 


Note 


Note 


Inventory overlapping reporting devices and mitigation devices. 


MARS supports round-trip policy audit analysis for reporting and mitigation devices that are both managed by 
Security Manager and monitored by a MARS Appliance. In other words, MARS can query the policy rules that 
generated an audit event log only when the policies are defined using Security Manager. As such, the first step 
in integrating MARS and Security Manager involves identifying those devices for which Security Manager is 
used to define policy rules. You must also ensure that devices are running a software versions supported by both 
MARS and Security Manager. 


This list focuses on those devices that Security Manager manages and should include all of the following devices: 


e¢ Cisco ASA appliances, PIX appliances, and FWSM modules 
e Cisco Catalyst 6500 Series Switches 
e Cisco Routers running supported versions of Cisco IOS software 


MARS supports PIX 7.0 and ASA 7.0.1 releases; however, it does not support FWSM 3.1. FWSM support is 
restricted to FWSM 1.1, 2.2, and 2.3. For current device support information, see Supported Devices and 
Software Versions for Cisco Security MARS. 


FWSM support is supported only in Cisco Security Manager Enterprise Edition (Professional-50) and higher, 
The Professional version includes support for the management of Cisco Catalyst® 6500 Series switches and 
associated services modules; the Standard versions do not include this support. 


Result: The list of devices for which Security Manager manages the security and audit log policies is defined. 
The details of each device include device name, reporting IP address, management IP address, management 
protocol, administrative account information, and the logging features, levels, and protocols to enable. 


For more information, see: 
¢ Supported Devices and Software Versions for Cisco Security Manager 3.0 
e Supported Devices and Software Versions for Cisco Security MARS 
e Selecting the Devices to Monitor, page 2-2 
e Levels of Operation, page 2-1 


e Deployment Planning Guidelines, page 2-1 in Install and Setup Guide for Cisco Security Monitoring, 
Analysis, and Response System 


e Device Inventory Worksheet, page 1-18 
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JY |tTask 


2. 


Tip 


Identify and enable all required traffic flows. 


After you identify the devices managed by the Security Manager server, you must verify that the network services 
they use for management, reporting, and notification are permitted along the required traffic flows. Using the 
detailed Device Inventory Worksheet identified in Step |., ensure that the management, logging, and notification 
traffic between the MARS Appliance and each supporting device, reporting device, and mitigation device is 
allowed by intermediate gateways. 


In addition, network services of supporting devices, such as DNS, e-mail, AAA, and NTP servers, must also be 
permitted to flow among the MARS Appliance, the supporting devices, and the reporting devices and mitigation 
devices on your network. 


It is a recommended security practice to have all devices, including MARS Appliances, synchronized to the 
same time. 
Result: You have verified that all intermediate gateways permit the log, management, and notification traffic 
between the devices and the MARS Appliance. 
For more information, see: 


e Deployment Planning Guidelines, page 2-1, in Install and Setup Guide for Cisco Security Monitoring, 
Analysis, and Response System 


e Supporting Devices, page 2-1, in Install and Setup Guide for Cisco Security Monitoring, Analysis, and 
Response System 


e¢ Required Traffic Flows, page 2-2, in Install and Setup Guide for Cisco Security Monitoring, Analysis, and 
Response System 


e Specify the Time Settings, page 5-10, in Install and Setup Guide for Cisco Security Monitoring, Analysis, 
and Response System 


e Event Timestamps and Processing in Top Issues for the Cisco Security Monitoring, Analysis, and Response 
System 


e Device Inventory Worksheet, page 1-18 
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JY (Task 


3. Bootstrap the reporting devices and mitigation devices managed by Security Manager. 


For each device identified in Task |., you must prepare, or bootstrap, that device to ensure that the desired 
communications with MARS occur. Bootstrapping a device involves configuring the settings for that device, 
based on its role in the STM system. Perform the following subtasks as applicable to a device type and its role: 


e Enable management of the device by the MARS Appliance for mitigation and access. 
e Turn on the correct logging level and logging services. 

e Direct the logs to the MARS Appliance. 

e Enable discovery of the device settings. 


Note While many Cisco devices support the EMBLEM syslog format, this format is not compatible with MARS. 
As part of this task, you must verify that the devices are not reporting to the MARS Appliance using the 
EMBLEM format. 


You must configure the router and switch settings using the CLI, as Security Manager does not support those 
features. However, for ASA, FSWM, and PIX, you can use the Security Manager user interface to configure the 
management and log settings. 


Tip Any events published by a device to MARS prior to adding and activating the device in the web interface can 
be queried using the reporting IP address of the device as a match criterion. This technique can be useful for 
verifying that the device is properly bootstrapped. 


You may also need to enable alternate settings on the to provide richer data. For more information on these possible 
settings, see Task 5 in the Checklist for Provisioning Phase, page 1-2 found in the STM Task Flow Overview chapter. 


Result: The correct logging levels are enabled on the reporting devices and mitigation devices. The MARS 
Appliance can receive or pull any necessary logs from those devices, and it can retrieve configuration settings 
and push ACLS to the supported mitigation devices. While the MARS Appliance picks up and stores the events 
it receives, it does not inspect them until the reporting devices and mitigation devices are defined and activated 
in web interface. 


For more information, see: 
e Device Inventory Worksheet, page 1-18 
¢ Bootstrap Summary Table, page 2-12 
e Cisco Router Devices, page 3-1 


e Cisco Switch Devices, page 3-9 


User Guide for Cisco Security Manager 3.0 


e Understanding Device Credentials 
See SNMP credentials. 
e Managing Firewall Devices (ASA, PIX, and FWSM) 
See device access, SNMP settings, logging policies, and static routes as needed. 


Note When defining SNMP settings for the FWSM and ASA, you should define these setting for the admin context. 


e Field definitions for the Logging Policies (ASA, PIX, and FWSM) 
e Managing Routers (Cisco IOS Routers) 
See device access, SNMP, 802.1x, NAC, and static routes as needed. 
e Using the Catalyst 6500/7600 Device Manager (Cisco Switches) 
See Spanning Tree Settings (STP). 
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4. 


Define the devices in MARS. 


After you identify and bootstrap the reporting devices and mitigation devices and enable the required traffic 
flows, you must represent those devices in MARS, which uses this information to communicate with the devices. 
You can do this by adding individual devices in the web interface or by importing a comma separated vector 
(CSV) file, which can define the required settings for basic device types and give you a headstart on defining the 
more complicated devices. After you add the devices, you must activate them by clicking Activate on any page 
in the web interface. 


To display all devices that are either added incorrectly or not activated in MARS, you can define one of two 
queries: 


¢ Select “Unknown Reporting Device” in the Devices field. This query returns the events only for those devices 
that are reporting events that do not matching the one of the reporting IPs defined in MARS. When MARS 
receives events, it first determines if the IP from which the events are received matches one of reporting IPs 
identified in the Reporting and Monitor Devices page. Only if MARS finds a match does it attempt to parse 
the events. Therefore, if the Reporting IP is defined incorrectly for a reporting device, the events from that 
device are not parsed. This query essentially identifies events that are not parsed. 


e Select the “Unknown Device Event Type” in the Events field. This query returns events from known devices 
that for some reason the event is not parsed by MARS (for example, if the MARS signature list is not current 
with the device event lists), and it returns events reported by unknown devices. 


For both queries, if you are looking for a specific reporting IP address, enter that address in the Keyword field to 
filter the results down to those that include that IP address. 


Result: All reporting devices and mitigation devices are defined and activated in MARS. When the devices are 
bootstrapped and defined in MARS, MARS begins to inspect the logs received from the devices. Until the devices 
are added in MARS, MARS picks up and stores the events it receives without inspecting them. 


For more information, see: 
e Device Inventory Worksheet, page 1-18 
e Selecting the Access Type, page 2-10 
e Add Reporting and Mitigation Devices Individually, page 2-17 
e Add Multiple Reporting and Mitigation Devices Using a Seed File, page 2-20 
e Adding Reporting and Mitigation Devices Using Automatic Topology Discovery, page 2-25 
e Cisco Firewall Devices (PIX, ASA, and FWSM), page 4-1 
e Cisco Router Devices, page 3-1 
e¢ Cisco Switch Devices, page 3-9 
e Supported Reporting and Mitigation Devices, page 2 (CSV Keyword column) 
e Verify Connectivity with the Reporting and Mitigation Devices, page 2-26 


e Activate the Reporting and Mitigation Devices, page 2-27 
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5. 


Note 


Bootstrap each Security Manager server and add it to the correct MARS Local Controller. 
The required setup of the Security Manager server is quite simple: 
e Verify that HTTPS is enabled on the Security Manager server. 
e Define an account with requisite privileges for use by MARS when performing policy queries. 
e Ensure that the MARS Appliance, as a host, has permission to access the Security Manager server. 


e Ensure the HTTPS traffic flows are permitted between the two hosts. You can verify connectivity by clicking 
Test Connectivity when defining a Security Manager server. It does not perform a lookup, but it does 
authenticate to the Security Manager server. 


Each Local Controller can only manage one Security Manager server. All policy lookups for syslog messages 
received on a Local Controller are directed to the Security Manager server configured for that 
Local Controller. 


In addition, you should ensure that the user account used by MARS is exclusive on the Security Manager server. 
An exclusive account allows you to more easily detect any fraudulent use of the account. 


MARS does not retrieve any audit log data from the Security Manager server. It merely accesses the set of policy 
rules that are defined on the server. 


Once you prepare the Security Manager server, you must return to the MARS web interface and add the 
Security Manager server. 


Result: The correct settings are enabled on each Security Manager server. The MARS Appliance can request and 
receive queries from no more than one Security Manager server. After adding the Security Manager server to the 
MARS web interface, you can test the connectivity by performing a policy lookup query on any of the events that 
have been received from one of the managed reporting devices and mitigation devices. 


For more information, see: 
¢ Bootstrapping Cisco Security Manager Server to Communicate with MARS, page 16-12 
e Add a Cisco Security Manager Server to MARS, page 16-13 
e¢ Supported Reporting and Mitigation Devices, page 2 


e Procedure for Invoking Cisco Security Manager Policy Table Lookup from Cisco Security MARS, page 
16-14 


Perform policy lookups as required. 


Once an event generated by one of the Security Manager-managed devices is received by MARS, you can perform 
a policy lookup operation. This operation allows you to, from a given incident or an event query, retrieve a list of 
the possible policies that could have affected the generation of that event from the Security Manager server. 


For more information, see: 
¢ More About Cisco Security Manager Device Lookup 
¢ More About Cisco Security Manager Policy Table Lookup 
e Prerequisites for Policy Table Lookup 
e Restrictions for Policy Table Lookup 
e Procedure for Invoking Cisco Security Manager Policy Table Lookup from Cisco Security MARS 
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Y_ |tTask 


7. Using Security Manager for mitigation response. 


While MARS suggests ACL changes to mitigate attacks, and in the case of Layer 2 devices such as Cisco 
switches, it can push changes to layer 2 device via the “Big Red” button (which shuts down a port on a switch), 
you must ensure accuracy between the policy defined in Security Manager and the configuration running on the 
managed devices. This synchronization ensures an accurate understanding of your network configuration and 
improves your ability to troubleshoot issues using the policy analysis tools provided in Security Manager. 


Therefore, we recommend that you perform the device mitigation by applying the rules recommended by MARS 
with Security Manager. This approach also prevents you from having to manually synchronize your policy 
between Security Manager and the mitigation devices. As an added benefit, you can enable and remove 
containment rules on multiple devices via global rules, thereby further restricting the spread of possibly 
undetected infections. Using comments in the rules, you can document the attack responses, allowing for future 
analysis when considering global network stances and when developing attack response strategies. 


Bootstrapping Cisco Security Manager Server to Communicate 
with MARS 


To prepare the Security Manager server to be queried by MARS, you must configure the following 
settings: 


e Define an admin account in Security Manager that MARS can use to perform queries. A separate 
account is recommended to provide a cleaner audit trail on the Security Manager server. The 
following security levels defined in Common Services 3.0 server satisfy the authorization 
requirements of MARS-to-Security Manager policy query: 


- Help Desk 

- Network Operator 

- Network Administrator 
- System Administrator 


wy 


Note Cisco does not recommend using System Administrator for this account. Instead, we recommend least 
privilege settings (only enabling those privileges required to perform the job). As such, we recommend 
defining an admin account with the Help Desk security level. 


For more information on defining admin accounts on the Common Services 3.0 server, see: 


http://www.cisco.com/en/US/products/sw/cscowork/ps3996/products_user_guide_chapter09186a0 
08022f958 .html#wp372210 


e Enable HTTPS access to the Common Services 3.0 server by the MARS Appliance. If you are using 
AAA authentication, such as Cisco Secure ACS, on the Common Services 3.0 server, you must 
update the administrative access settings to ensure that the MARS Appliance has the necessary 
access to the Security Manager server. 


e Before MARS can query the policies defined on the Security Manager server, you must enable 
HTTPS on the Security Manager server. For more information on enabling HTTPS, see: 
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http://www.cisco.com/en/US/products/sw/cscowork/ps3996/products_user_guide_chapter09186a0 
08022f958 html#wp33945 1 


Add a Cisco Security Manager Server to MARS 


Step 1 
Step 2 


Step 3 


Step 4 


Step 5 


The Security Manager server is represented in MARS by defining a host with a software application 
residing on that host. Once you have identified the reporting devices to a Local Controller, you can add 
the Security Manager server that manages the policies for those reporting devices. 


Each Local Controller can query one Security Manager server only; you cannot define more than one 
Security Manager server per Local Controller. You can define the same Security Manager server on 
multiple Local Controllers. When planning the zones for Global Controller/multi-Local Controller 
deployments, ensure that each Local Controller maps to the Security Manager server that manages the 
reporting devices monitored by that Local Controller. 


To identify a Security Manager server to use for policy lookups from within the web interface of MARS, 
follow these steps; 


Select Admin > System Setup > Security and Monitor Devices > Add. 
Do one of the following: 
e Select Add SW Security apps on a new host from the Device Type list, and continue with Step 3 


e Select Add SW security apps on existing host from the Device Type list. Select the device to which 
you want to add the software application and click Add. Continue with Step 6. 


Specify values for the following fields: 


e¢ Device Name — Enter the name of the device. This name must exactly match the hostname shown 
in the Cisco Security Manager user interface. MARS maps this name to the reporting IP address. 
This name is used in topology maps, queries, and as the primary management station in the Security 
and Monitoring Device list. 


e Access IP — This s address is used to pull query data from a Security Manager server using HTTPS, 
enabling MARS to discover settings and perform policy queries from this device. This address 
represents the physical IP address of the Security Manager server. To learn more about the access 
IP address, its role, and dependencies, see Understanding Access IP, Reporting IP, and Interface 
Settings, page 2-8. 


e Reporting IP — (Optional) If the Security Manager server is host to a reporting device other than 
Cisco Security Manager, enter the IP address of the interface in the Security Manager server from 
which MARS. This address represents the physical IP address of the Security Manager server. To 
learn more about the reporting IP address, its role, and dependencies, see Understanding Access IP, 
Reporting IP, and Interface Settings, page 2-8. 


e Operating System — (Optional) If the Security Manager server is host to a reporting device other 
than Cisco Security Manager, you may need to specify the operating system type. 


Under Enter interface information, enter the interface name, IP address, and netmask value of each 
interface in the Security Manager server from which configuration information will be queried. 


This address represents the physical IP address of the Security Manager server. This information is used 
to ensure that the topology generated by MARS represents all network connections for the 

Security Manager server. It is also used to calculate possible attack paths that might include the 
Security Manager server. 


Click Apply to save these settings. 
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Step6 Click Next to access the Reporting Applications tab. 
Step7 Select the Cisco Security Manager ANY from the Select Application list, and click Add. 


Step8 — If you entered an address in the Access IP field on the host that represents this Security Manager server, 
specify values for the following fields: 


e User Name— Identifies the Cisco Security Manager administrative account to be used to discover 
configuration settings. 


e Password — Identifies the password associated with the User Name account. 


e Access Type — This value identifies the protocol used to discover configuration information. Select 
HTTPS. 


e Access Port — The default access port for HTTPS is port 443. 


Step9 (Optional) To verify that the settings are correct and that the MARS Appliance can communicate with 
this Security Manager server, click Test Connectivity. 


Result: If the username and password are correct and the MARS Appliance is configured as an 
administrative host for the device, the “Connectivity successful.” dialog box appears when the discovery 
operation completes. Otherwise, an error message appears, which you can click on the View Error link 
for more information. 


Step 10 To add this device to the MARS database, click Submit. 


Result: The submit operation records the changes in the database tables. However, it does not load the 
changes into working memory of the MARS Appliance. The activate operation loads submitted changes 
into working memory. 


Step11 Click Activate. 


Result: Once the MARS Appliance is activated, it can query the Security Manager server to perform 
policy lookups. 


Procedure for Invoking Cisco Security Manager Policy Table 
Lookup from Cisco Security MARS 


Do the following steps to view a Cisco Security Manager policy table from the Cisco Security MARS: 


Step 1 Log on to MARS as an Administrator or Security Analyst. 
Step2 Identify the incident or event to investigate. 


In this procedure, and incident to investigate appears on the Recent Incidents section of the Dashboard, 
as shown in Figure 16-2. 
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Step 3 


Step 4 


Procedure for Invoking Cisco Security Manager Policy Table Lookup from Cisco Security MARS [il 


Figure 16-2 Recent Incidents on MARS Summary Page 
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Click Incident ID of the incident to examine. The Incident Page appears as shown in Figure 16-3. 


Figure 16-3 MARS Incident Page Displaying the Cisco Security Manager Icon in the 
Reporting Device Field 


Cisco Systems 
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12289917483. connection[a]@ Feb 21, 2006 5:32:08 PM PST wy 
1 $:2305622787, Built/teardown/permitted IP 10,2.3.58 [4] 58104 [@) 10,1.1.147 [@) 443 [@) TCP [@) Feb 21, 2006 5:32:09 PM PST - cherryWall fa [e) False Positive 
1:2289917483.8 connection [a]@ Feb 21, 2006 5:32:24 PM PST x 
< 
6K 
Copyright © 2003, 2005 Cisco Systems, Inc, Summary :: Incidents :: Query / Reports :: Rules :; Management :: Admin :: Help :: [ Feedback 5 
All rights reserved es) 
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Click the Security Manager Policy Query icon in the Reporting Device field to invoke the 
Security Manager policy table lookup. One of the following three pop-up windows may appear: 


- Multiple Events window— Lists all Security Manager device events in the session, this window 
appears in this step when there are two or more events in the session. 


- Multiple Devices window—Lists all matching Security Manager devices that meet criteria 
available to MARS, this window appears in this step when there are two or more matching 
devices. 


- Policy Table window—Lists the policy table of the reporting device. Access rules that match 
the MARS criteria are highlighted, this window appears in this step when there is one event and 
a unique Security Manager device identified. 


In this procedure, the Multiple Events window appears, as shown in Figure 16-4. 
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Figure 16-4 MARS Multiple Events Pop-up Window 


Cisco SYSTEMS 


Local Controller: LC44/LC44_zone v4.2 Login: Local: Administrator (pnadmin) :: 


There are multiple events found. Please click on the policy query of the interested event to display policies 
related to it. 


Event / Session / |Reporting |Time Raw Message 
Incident ID Device 


E:2305620876, cherryWall Feb 21, 2006 B24 <134>Feb 21 2006 17:26:42: %PIX-6-302013: Built inbound TCP 
$:2305620876, 5:30:33 PM connection 1689482 for outside:10.2.3.58/58062 

1:2289917478a PST (10,2.3.58/58062) to inside:10.1.1.147/443 (10.1.1.147/443) 
E:2305622676, cherry Wall Feb 21, 2006 B24 <134>Feb 21 2006 17:28:10; %PIX-6-302014; Teardown TCP 
$:2305620876, 5:32:02 PM connection 1689482 for outside;10,.2.3,58/58062 to 
112289927483. PST inside:10,1,1.147/443 duration 0:01:28 bytes 15 TCP Reset-I 
Copyright © 2003, 2005 Cisco Systems, Inc. 


bom 
M~ 
4ll rights reserved. a 


Step5 Click the Security Manager icon in the Policy field of the appropriate event. One of the following two 
pop-up windows may appear: 
- Multiple Devices window 


- Policy Table window 


In this procedure the Multiple Device pop-up window is displayed, as shown in Figure 16-5. 


Figure 16-5 MARS Multiple Devices Pop-up Window 


Cisco SYSTEMS 


Local Controller: LC44/LC44_zone v4.2 Login: Local: Administrator (pnadmin) :: 


Multiple devices matched the selection criteria in CSM. Please select the interested device from the list. 
|__|ip Address|Host Name[Display Name 
ep (lial cherryWall cherry Wall.protego.cisco.com protego.cisco,com 


Cc 10.2.2.3 cherryWall cherry Wall.cisco.com cisco.com 


Copyright © 2003, 2005 Cisco Systems, Inc. 
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Step6 Click the radio button of the appropriate Security Manager Device. Click Submit. The Policy Table 
pop-up window appears for the selected device, as shown in Figure 16-6. 


User Guide for Cisco Security MARS Local Controller 
Pie-16 Tal 


| Chapter16 Policy Table Lookup on Cisco Security Manager 
Procedure for Invoking Cisco Security Manager Policy Table Lookup from Cisco Security MARS [il 


Figure 16-6 Policy Table Pop-up Window 
Cisco Security Manager 
Cisco SysTEMS 


Local Controller: LC44/LC44_zone v4.2 Login: Local: Administrator (pnadmin) :: 


Event / Session / |Event Type Source IP/Port Destination i Reporting |Path / 

Incident ID IP/Port Device Mitigation 
£:2305620876, Built/teardown/permitted IP ——-10.2.3.58 [a] 58062 [a] 10.1.1.147 [d] 443 [a) TcP [a] Feb 21,2006  cherryWall False 
$:2305620876, connection[g]@ 5:30:33 PM x Positive 
1:2289917478@ PST 


Total policies returned: 14, Number of matched policies; 2, Jump to matched policy: | First Last 


Source Destination i ir. i Category Description Prev/Next 


Local ( 14 am i 


2 Vv 10,.10.0.0/16 a any : Syslog outside None 
3 Vv 10,10.0.0/16 ic) any $$ SNMP-Trap outside in LOG None 
4 Vv 10.4.0,0/16 io-} any $ Syslog outside in LOG None 
5 Vv 10.4.0.0/16 a any $ SNMP-Trap outside in LoG None 
6 Vv 10,10.0.0/16 io) any bcd ICMP-Echo-Reply outside in LOG None 
7 Vv 10.4.0.0/16 = any bcd ICMP-Echo-Reply outside in LOG None 
8 Vv 10.2.0,0/16 a any bcd ICMP-Echo-Reply outside in LOG None 
9 Vv 10.2.3.46 as any . HTTPS outside None 
10.2.3.0/24 = any r) HTTPS outside None 
12 = 10.2.3.8 128.107.234.204 §$ smTP outside in LOG None 
13 y 10.2.3.8 171.70,168.183 $ DNs-UDP outside in LOG None 
4wy 10.2.3.0/24 ap any $$ SMTP outside in LOG None 
1 to 14 of 14[28 per pase 

ur 

B 
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The access rules that match the MARS query criteria appear in highlight. The access rules displayed in 
the Policy Table window are derived from the Security Manager committed view, not the deployed view. 
You must login to Security Manager or the specific device to examine or alter the access rule generating 
the MARS event or incident. If the committed and deployed views are identical, locating the policy is 
simplified. A MARS event can be generated from a deployed access rule not visible in the 

committed view. 


Step7 Login to Cisco Security Manager or the specific device to alter the security rule creating the MARS 
event. 


This ends the Procedure for Accessing Cisco Security Manager Logs from Cisco Security MARS. 


Note Incidents, events, and sessions related to devices managed by Cisco Security Manager can also be 
viewed with an inline Query or a report. 
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Network Summary 


This chapter describes the web interface and the components of the Summary tab of the web interface. 


Navigation within the MARS Appliance 


Logging In 


Step 1 


Step 2 


Step 3 


The MARS web interface runs within a single brower window. The MARS product functions are 
categorized with labeled tabs, each tab subdivided with subtabs. 


To login to the Local Controller, enter its IP or DNS address into the browser address field. The login 


box appears. 
Figure 17-1 Local Controller Login Box 


Cisco Systems 


Login Name: |onadmin | 


Password: ok OK 
Type: Local 


143161 


Enter your login name and password. If you do not have a login name, contact your network 
administrator. 


From the Type drop-down list, select Local if you are logging in to a user account created on this MARS, 
or select Global if you are logging in to a user account created on the Global Controller to which this 


Local Controller reports. 


User Guide for Cisco Security MARS Local Controller | 


| 78-17020-01 


Chapter17 Network Summary | 


HI Navigation within the MARS Appliance 


Step4 = Click Login. 


The first page to appear after a login is the Summary tab Dashboard page. The duration of the delay in 
displaying information results from a combination of the following causes: 


¢ How long the Local Controller has been powered up and connected to the network. 
e Amount of traffic on your networks 

e Reporting syslog levels of the reporting devices 

e Size of the network 

e The number and type of reporting devices 


For most networks, the Summary page populates shortly after configuration. Some values are only 
relevant after an interval of time. For example, the values in the 24 Hour Events and 24 Hour Incidents 
tables. 


Basic Navigation 


The Local Controller uses a tab-based, hyperlinked user interface. When you mouse over an 
alphanumeric string or an icon that is a clickable hyper-link, the mouse cursor changes to a pointing 
finger cursor We Figure 17-2 shows some of the clickable objects on the Dashboard page. 


Figure 17-2 Links, Icons, and Filters 

[Green <] [all Rules = [all Case Statuses ¥| 

Incident ID Event Matched Rule Action|Time Path |Cases 
Type 

1:10300958@3 Inactive Try it-Dub05.03.08/09:01:23[4) Alert Aug 30, €:119753 (Assigned) 
reporting 2005 Follog-up &Y oN 
device 10:00:02 bs 
detected[q] AM CDT ¢ 


@) @ 


1 |Link to the item’s detail page or popup 2 /|Query icon links to query page. The 
window. corresponding query field is populated with 
the item. 
3 | Pulldown lists filter what is displayed. 4 |Path icons launch Path or Incident Vector 
pop-up diagrams. 


Click any of the seven tabs to navigate to the pages relevant to the tab’s sub-tabs, as shown in Figure 17-3 
though Figure 17-8. 


Figure 17-3 Summary Tab 


Cisco SYSTEMS 


[Summary | INCIDENTS |] QUERY / REPORTS |/ RULES || MANAGEMENT || ADMIN || HELP 


5 [ } 
(WO) summary | CS-MARS Standalone: LC20-Doc v4.1 Login: Administrator (pnadmin) :: [Logout | +: 


143168 
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Figure 17-4 Incidents Tab 
Cisco SYSTEMS 
[som REBERN[ver erons [nos Lwanacenenr [own [ver 
=] 
Sy & 


Figure 17-5 Query/Reports Tab 


Cisco SYSTEMS 


[summary | mcroenrs [RARE ues J[ manacemenr [Aone [ve | 


Es 
—f 


Figure 17-6 Rules Tab 


Cisco SYSTEMS 


[man [wanes [ove rons EY acco [aon [a] 


Figure 17-7 Management Tab 


Cisco SYSTEMS 


[mma [mcoows [ou rors [a RAS on [vr 
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Figure 17-8 Administration Tab 


Cisco SYSTEMS 


(omar [wanes [aur aeons [as [nancone [ASAT] 


143151 


Figure 17-9 Help Tab 


Cisco SysTEMs 


oon 


SUMMARY || INCIDENTS || QUERY / REPORTS || RULES MANAGEMENT | 


[sgour] # [actvae ] $9 
= 
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Help Page 


The Help page, as shown in Figure 17-10, provides URLs to online documentation and a feedback form 
to submit constuctive comments to the MARS development engineering team. 


Figure 17-10 Help Page 


Cisco Systems 


SUMMARY || INCIDENTS |} QUERY / REPORTS || RULES || MANAGEMENT || ADMIN [net | 
> eS SSS SSS Ss 


8 HELP | CS-MARS Standalone: LC20-Doc v4.1 Login: Administrator (pnadmin) :: | Logout | ii | Activate 


About / Documentation 


About 


Documentation 


143393 


Copyright © 2003, 2005 Cisco Systems, Inc Summary ;: Incidents :; Query / Reports ;; Rules :: Management :; Admin :: Help :: [Feedback 
All righ ed 


Click About to display the software version number running on the MARS. 


Click Documentation to display URLs to MARS documentation on the Cisco Systems, Inc. website 
(http://www.cisco.com). 


Your Suggestions Welcomed 


The Feedback button appears at the bottom of most pages, a shown in Figure 17-10. 


When you click the feedback button, or navigate to the Feedback page, the feedback dialog box appears, 
as shown in Figure 17-11. 
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Figure 17-11 Feedback Dialog Box 
Cisco SYSTEMS 


Standalone: LC20-Doc v4.1 Login: Administrator (pnadmin) :: 


Contact Email: | (— 


The return email address can be set permanently via User Management. 


Subject: CC 


Include log files: = [— 


Message: 


143158 


To send your comments to the MARS development engineering team, type in your email address and 
comments then click Submit. When you click the Include log file a MARS log file is sent with your 
message. 
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Summary Page 


From the Summary pages, you can very quickly evaluate the state of the network. The Summary pages 
include the Dashboard, Network Status, and My Reports, a shown in Figure 17-12. 


Figure 17-12 Summary Tab 


Cisco SYSTEMS 


[summary | INCIDENTS || QUERY / REPORTS |/ RULES || MANAGEMENT || ADMIN || HELP 


WA summary | CS-MARS Standalone: LC20-Doc v4.1 Login: Administrator (pnadmin) +: | Logout | ¢: 


143168 


Dashboard 
, 


Note When you first view the Summary page after upgrading the Local Controller, expect a small delay while 
the Java Server pages recompile. 
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Figure 17-13 


@O> 


Cisco SysTEMs 


Dashboard 


The Working Areas on the Dashboard 


WY summary | CS-MARs Standalone: LC20-Doc v4.1 


(2)> Select Case: [No Case Selected... | 


Follow-up &Y 
(3)> 118855 (New) New Case 
xg 


(4)——> 


Page Refresh Rate 
15 minutes fe] 

24 Hour Events 

HB netflow 0 

WB Events 5,825 

W) Sessions 4,890 
Data 16% 
Reduction 

24 Hour Incidents 

WE High 220 49% 

© medium 207 46% 

HB bow 16 3% 
Total 443 100% 

All False Positives 

WE To be 0 0% 
confirmed 

HB system 0 0% 
determined 


Logged Oo 0% 
WB Dropped 0 0% 


User 0 0% 

confirmed 

Total 0 100% 
To-do List 


€:119753 (Assigned) 


My Reports 


No Reports Selected 


Edit 


Subtabs 


Recent Incidents 


All Severities =] 


Summary Page 


INCIDENTS 


QUERY / REPORTS |/ RULES || MANAGEMENT 


ADMIN 


HELP <(5) 


All Rules =] 


Login: Administrator (pnadmin) :; [Logout] #: [ 


Activate | 


View Cases 


New Case 


Assigned =] 


Incident ID Event |Matched Rule Action|Time Path |Cases 
Type 
1:10300958.9 Inactive Try it-Dub05.03.08/09:02:23 [3] Alert Aug 30, Bk] C:119753 (Assigned). 
Gas 2005 Follow-up AY 
MARS. 10;00;02 
reportin: AM CDT 
device 
HotSpot Graph Attack Diagram 
Full Topo Graph Large Graph _|[Help Large Graph _|[Help 
B, 
sompttras 
2. a re | - 
mm A 
fine ach 
Events and NetFlow , last 1d-0h Events and Sessions, last 1d-0h 
Day =] [barge chart] [Legend Day Large Chart || Legend 


Chart resolution: 30Min 


Tue 8AM Tue 3PM Tue 11PM Wed 6AM 


Chart resolution: 30Min 


Tue 8AM Tue 3PM Tue 11PM Wed 6AM 


Activity: All Events and Netflow - Top Destination 
Ports, last 1d-Oh 


Total view |=) [Day | 


View Report 


Legend 


Chart resolution: 30Min 


Tue 1PM 


Tue 3PM 


False Positive Events, last 1d-0h 


Day fe) |_Large Chart 


Legend 


Chart resolution: 30Min 
Aug/Min 


0.95 
0.85 
O75 
0.65 
0.55 
0.45 
0.35 
0.25 
0.15 
0.05 


HHH HEHEHE 
Tue 3PM Tue 11PM 


HHH 


Tue SAM Wed 6AM 


HHH 
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Tabs 


Case Bar (Local Controller only) 6 


Recent incidents information 


Links to Cases assigned to you. 7 


HotSpot and Attack diagrams 


FS) wo, n; = 


Charts 
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Recent Incidents 


The first feature to notice about the Dashboard are the recent incidents that have fired. The 
Local Controller comes with pre-defined rules, and these incidents are the result of those rules firing. 


These rules are generic, globally applicable, and should serve you well as a starting point once you begin 
to tune the Local Controller. 


Figure 17-14 Drilling-down into Incidents 


[Green <] [all Rules ~] [all Case Statuses ¥| 
Incident ID Event Matched Rule Action|Time Path |Cases 
Type 
1:10300958@ Inactive Try it-0ub05.03.08/09:01:23[g) Alert Aug 30, [] Bx] c:119753 ame 
reporting 2005 FollowAip & 2 
device 10:00:02 = 
detected|q] AM CDT | iw g 
@ 
1 |Link to the Incident sessions detail page 5 |Link to the rule details page 
2 (Incident severity icons 6 (Incident Path icon launches the topology 
fa Red—Severe threat diagram popup window 
£% Yellow—Possible threat 
 Green—Unlikely threat 
3 |Link to the Event Type Details page 7 {Incident Vector icon launches the incident 
attack vector diagram 
4 (Query icon links to Query page [a] 8 Link to the View Case page 


Sessions and Events 


Within a given time window, a session is a collection of events that all share a common end-to-end: 
e Source and destination address 
e Source and destination port 


e Protocol 


Event sessionization aggregates event data making it easier to sort and examine. Event sessionization 
lets the system treat events as single units of information and helps you understand if an attack truly has 
materialized. It gives you the context of the attack by giving you all the events on that session. 


Sessionization works across NAT (network address translation) boundaries — if a session traverses a 
device that does NAT on that session, the Local Controller is able to sessionize events even if they are 
reported by two devices on either side of that firewall. 


Networks start to show immediate action in the events and sessions categories. Note that the 24 Hour 
Events table and the Events and Sessions chart are different ways of presenting the same information. 
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Data Reduction 


Data Reduction is a representation of how much event data the Local Controller collapsed into sessions. 
For example a data reduction of 66% measures three events per session on the average — this number is 
dependent on many variables particular to your network. 


Figure 17-15 Data Reduction 


24 Hour Events 

WB Netflow 02 

MM Events 

Ms 
Data 
Reduction 


ons 
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Page Refresh 


The Page Refresh Rate polls the Local Controller according to the setting you assign. The default setting 


is fifteen minutes. The refresh setting remains the same until you log out. This setting only applies to the 
pages that have the Page Refresh pull-down. 


Figure 17-16 Page Refresh 


[Page Refresh Rate ai 


15 minutes |} 


[24 Hour Events } 
HB Netflow i) 


MB Events 2,132,436 
' Sessions 462,803 
= 
Data 78% z 
Reduction ¢ 
t 


& 


Note You can change the refresh rate with the dropdown list. 


Diagrams 


The Summary page has two diagrams: the Hot Spot Graph and the Attack Diagram. Local Controller 
uses the configuration and topology discovery information that you provide to generate these diagrams. 
The following table shows you the icons used in the diagrams. 


You can start drilling-down into the diagrams by clicking any of the icons listed in Table 17-1 on 
page 17-10. You can start drilling-down attack paths in the Attack Diagram by clicking the Path icon [8]. 


Drilling-down into these diagrams is one of the fastest ways to uncover real-time information about your 
network. 
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Figure 17-17 Clickable Hot Spots: Brown = Attackers & Red = Compromised 
Dal rT 
| = 


S 


Note Clouds can represent collections of gateways in the Hotspot graph. A gateway cloud is a device that is 


unknown to the Local Controller. You can discover gateway clouds by clicking them if you have the 
SNMP information. 


Table 17-1 Icons and States in Topology 


Compromised and 
Healthy Attacker Compromised Attacking 


Clouds - __ —_ = 
Firewall aan ale, al 
Reporting Host B, B B B 
= o pe D, A, 
= S al a] S| 
Network —= — —4 xs 
aa a) fe 
Switch S rl ra g 


To see the diagrams, you need the Adobe SVG viewer plug-in. The Adobe SVG viewer plug-in should 
automatically install. 


\ 


Note If you click No on the SVG auto-installer, the Local Controller does not prompt you to install it again. 


If you want to run the auto-installer, open the browser and click Tools > Internet Options > General > 
Delete Cookies. 
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Figure 17-18 The Hot Spot Graph and Attack Diagram 


HotSpot Graph 


LC31 Attack Diagram 


1 |Displays SVG Help 2 |Displays clouds for selected devices on a full 
page 

3 |Displays all devices on a full page 4 Selects zone to be displayed (Global 
Controller only) 


5 Selects zone to be displayed (Global Controller only) 


Manipulating the Diagrams 
e Right-click the diagram to zoom in and out, to reset the diagram to its original size, to set the 
diagram’s viewing quality, to search, and to manipulate the SVG image. 
e Alt+click to use the hand to move the image. 
e Ctrl+click to use the magnifying glass to zoom in. 
e Ctrl+click and drag to select an area. 


e Ctrl+shift+click to use the magnifying glass to zoom out. 
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Note If the Local Controller discovers an unknown device, it displays that device using a unique name in the 
form of the string “eth” followed by a hyphen (“-’’), followed by the IP address in 32 bit notation, such 
as “eth-168034561”. 


Display Devices in Topology 


You can specify how to display a reporting device in the HotSpot Graph. By clicking the icon in the 
Device Display column, you can specify whether to display the device as an individual node on the graph 
or collapse it within a cloud. By having a device “hidden” in a cloud, you can cut down on the number 
of devices displayed in the graph, thus making it easier to read at a higher level. 


A cloud identifies a collection of networks for which you do not want to define the complete physical 
topology. Much like when you draw a network diagram on a piece of paper, you can use a cloud to depict 
networks in which you have no direct interest, but which are needed to represent to complete the 
diagram. For example, you may want to display only gateway devices or mitigation devices, representing 
other reporting devices as part of a cloud. 


To toggle the display status of a device, follow these steps: 


Step1 Click Admin > Security and Monitor Devices. 


Step2 Click the icon in the Device Display column of the device that you want to toggle. 


Figure 17-19 The Device Display icons 


Device 
Display 


The icon changes from a host icon to a host within a cloud or vice versa. 


Step3 Click Activate. 


Network Status 


The Network Status page is where you come to get the big picture. On the Network Status page, you can 
see the charts for: 


e Incidents 
Rated by severity. 
e Attacks: All - Top Rules Fired 
Rated by the highest number of incidents fired. 
¢ Activity: All - Top Event Types 
Rated by the highest numbers of events of that type. 
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e Activity: All - Top Reporting Devices 
Rated by the total number of events reported by each security device. 
e Activity: All - Top Sources 
The top IP addresses that appear as session sources, ranked by session count. 
¢ Activity: All - Top Destinations 
The top IP addresses that appear as session destinations, ranked by session count. 


For all of the charts on this page, you can set different time frames, the size of the chart, view the latest 
report, and so on, by clicking on the buttons in the chart’s window. 


Reading Charts 
These are stacked charts. You can tell which severity of incident your network has most experienced for 


the day by looking for the dominant shade. In the figure below, low priority green incidents cover less 
area than high priority red incidents because they have occurred less often. 


Figure 17-20 A Day’s Events and Netflow with the Legend Displayed 


Incidents, last 1d-\wi:00m 


Day _|¥|[Sum Zones M|[_Large Chare_J[ Legend ] 


Chart resolution: 30m 


Avg/Min 
165 


Tue SAM Tue 1PM Tue SPM Wed 4AM Wed 11AN 
Color Most Recent / Minute Value —~ 
m= 64 514 [a] 
= 4.9 8444 [q] 
= 4.8 80 [a] 
EJ 4.5 135 [4] 
st] 44 Non-TCP/UDP [a] >—H{ 5 ) 
=| 3 2998 [g) 
| 2.9 110 [a] 
= 2.6 161 [a] 
a 2.3 138 [g) 3 
i 2 902 [a] __ J 8 


1 |Displays values by hour, day, week, month, [2  |Sets chart to represent the sum of all zones or 
quarter (the last 3 months), or year. each individual zone (Global Controller only). 


3 |Displays a larger version of the chart. 4 Displays the chart legend. 
5 |The chart legend 
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To read the charts most efficiently, note that it is solely the thickness of a particular color that determines 
its value at that point — and that a spike (or drop) in any particular color could be caused by a spike (or 
drop) of a different color lower down in the stack. 


A perfectly flat line indicates that Local Controller received no data during that time period. 


Figure 17-21 A Flat Line in a Week’s Top Rules Fired 


Attacks: All - Top Rules Fired, last 1ww:idd:Ohh 
Per Minute 
0.7 
0.66 
0.62 
0.538 
0.54 
0.5 
0.46 
0.42 
0.38 
0.34 
0.3 
0.26 
0.224 
0.18 
O14 
0.1 
0.06 = 
0.02 avery Weare g 
Sun, Oct12 Tue, Octi4 Thu, Oct16 Sat Oct /8 Mon, Oct 20 9 


1 |The flat line in the Top Rules Fired chart 


In the following Incidents chart, you can see the top incidents for the week, starting eight days in the past. 


Figure 17-22 Eight Days of Incidents 


Incidents, last 8dd:Ohh 


Per Minute 


Tue, Aug 26Thu, Aug 28 Sat, Aug 30 Sun, Aug 31 Tue, Sep 2 


1 |Amore drastic spike in red is not offset by the |2  |Incident spikes are built upon each other 
green incident 
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My Reports 


The My Reports page is where you can choose the reports that you want to view. As long as you are using 
the Local Controller with your log in name, the reports that you have selected appear here. 


To set up reports for viewing 


Step 1 Click the Edit button on the My Reports page. 
Step2 Select the radio button next to the report that you want to see as a chart. 
Step3 Click Submit. 
Local Controller now displays the chart that you selected on the My Reports page. 


wy 


Note Reports must be scheduled to run periodically, that is, every hour or every day. If you activate a report, 
allow for some time for the data to accumulate. 


You can display any number of charts on the My Reports page, however expect slower loading times for 
large numbers of charts. 


The reports that you can select from are pre-defined. When you create your own reports, you can select 
those to display. See Reports, page 20-22 for more information. 
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CHAPTER 1 


Case Management 


This chapter contains the following sections: 


Case Management Overview, page 18-1 
Hide and Display the Case Bar, page 18-3 
Create a New Case, page 18-4 

Edit and Change the Current Case, page 18-5 
Add Data to a Case, page 18-6 


Generate and Email a Case Report, page 18-7 


Case Management Overview 


\ 


The Case Management feature can capture, combine, and preserve user-selected MARS data within a 
specialized report called a case. The following data can be added to a case: 


Text annotations 

Incident ID page 

Incident device information (source IP address, destination IP address, reporting device) 
Session Information page 

Query Results page 

Build Report page 

Report Results page 


View Case page (the current case can reference another case) 


Any user can create or alter any case. You can assign a case to a MARS user on the same machine, and 
can change the status of a case to assigned, resolved, or closed. The contents of a case are displayed by 
category on a single GUI page (View Case), and can be automatically assembled into a single HTML 
case document. You can email the Case Document to any MARS user account or user group. 


Note 


When a case is closed, you can still email it, annotate it, add device information, and include a reference 
to another case. 


Case information collected on incidents, sessions, queries, reports and mitigation logs are forensic 
evidence pertinent to the following: 
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e Audits (for example, regulatory compliance audits) 
e Justifications for modifying ACLs or policy changes 
e Notes for MARS false positive tuning 

e Examples of allowed and prohibited behavior. 


The case preserves and displays the selected data as it appeared when the data was added to the case, 
regardless of subsequent changes to the MARS state. For example, MARS data can be purged, topology 
can change from automatic discoveries or vulnerability scanning, and overall configuration can change 
when you edit rules or reports, but the data reported in the case remains the same as the time it was 
captured. 


Note As of MARS software version 4.1.1 the Case Management feature replaces the incident escalation 
feature. 


The Case Management homepage is the Cases subtab of the Incidents tab as shown in Figure 18-1. 


Figure 18-1 Case Management Tab—Local Controller 
Cisco SysTEMs 
SUMMARY || INCIDENTS || QUERY / REPORTS || RULES || MANAGEMENT || ADMIN || HELP 
[incidents |[ False Positives |[ Cases |[ Sep 12, 2005 10:11:53 AM CDT 
S)? INCIDENTS | CS-MARS Standalone: LC20-Doc v4.1 Login: Administrator (pnadmin) +: [ Logout | t? [ Activate 


Cases Case ID Show 


All Severities je] [ All Statuses le) All Owners = Search 


Q@)> 


Case ID 
01213308 


Owner Summary Created / Updated 
: Confetti attack 


Martuc 


11212848 
C:11975328 Assigned 
€:119662 8 New 


c:118855.a New Admini 


(pnadmin) 


c:1183288 Assigned MeNutt, Blaine (rbmenutt) 
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Summary +; Incidents :; Query / Reports :; Rules :; Management ;: Admin :; Help Feedback 


1 |Case Bar 2 |Dropdown Display Filters 


3 |Individual Cases 


All new, assigned, resolved and closed cases can be accessed from the Cases subtab. 


To view the contents of a case, click the Case ID number of a case. The View Case page appears, as 
shown in Figure 18-2. 


To generate an HTML document of the View Case page content that can be emailed, click 
View Case Document at the bottom of the View Case page. Graphs and charts plotted from reports are 
also captured in the Case Document. 
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Figure 18-2 The View Case Page—Local Controller 


Cisco Systems 


SUMMARY |] INCIDENTS |) QUERY / REPORTS || RULES || MANAGEMENT || ADMIN || HELP 


Incidents || False Positives || Cases Aug 29, 2005 9:50:11 AM PDT 


eM INCIDENTS | CS-MARS Local Controller: pluto/pluto v4.1 Login: Local: Administrator (pnadmin) i: [ Logout ] if [ Activate 


Current Case: €:209418 (Assigned) MARS Defends Mores 


Case ID: fiosgis Show 
(2) view Case: C:109418 
Case ID Status Owner Summary 
C:109418 et Assigned Local: Administrator (pnadmin) MARS Defends 22 AM PDT 
11 AM POT 


Select/Edit This Case 


Case History 


User Action Comment Time 


ce sened 


Local: Administrator (pnadmin) 


Local Initial d 
Local rator (pnadmin) Initial ary 4 norm M PDT 
Local: Administrator (pnadmin) Initial Owner: pnadmin M PDT 
Local: Administrator (pnadmin) Initial y: Yellow M PDT 
Local: Administr pnadmin) C 4 AM PDT 
Local or (pnadmin) 14. AM PDT 
Local: A Added: $:5458092 Auc PM PDT 
Local: Ad ) Added: 3.1.5.5 PM PDT 
Local ) 108300 (New) New PM PDT 
Local: Adm pnadmin) Pr anged: Red PM PDT 
Local: Admi pnadmin) R Activity: All - Top Destination Ports (Peak View) PM PDT 
Local: Administrator (pnadmin) Summary Changed MARS Defends 114 AM PDT 
Sessions 
Display|Session / Incident 1D [Events Source IP/Port [Destination IP/Port [Protocol [Time Reporting Devices [Path / Mitigation |Tune 
vw $:5458092, Inactive reporting device detected[g)@ 0.0.0.0 [a] 0 [a] 3.1.5.5 [a] ofa) N/A fg) Sug 16, 2005 3:00:02 AM PDT pluto faa N/A False Positive 
1:5336608@", 
1:5336612@, 
1:5336611@", 


1:5336613.2, 
1:5336610@ 


Devices 
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Display Device 


1 |Case Bar—Identifies current case 2 |View Case identifier—Shows the attributes of 
the case 


3 |Case History—Log of all changes made tothe 4 |Summary of data added to the case 
case 


Case Management Considerations for the Global Controller 


Case management on the Global Controller differs from the Local Controller implementation as follows: 


e Cases are not created on a Global Controller. 
They can be viewed and modified. 


e The Global Controller does not have a Case Bar. 
All Cases are selected from the Incident -> Cases page. 


e The Cases page has an additional dropdown filter to display cases per Local Controller. 


Hide and Display the Case Bar 


The Case Bar displays by default. When displayed, the Case Bar appears at the top of each page. The 
Case Bar must be displayed to create or modify a case. 


Hiding the Case Bar 
To hide the Case Bar, perform the following steps: 
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Step 1 


Step 2 


Step 1 
Step 2 


Navigate to the Cases subtab (Incidents > Cases), as shown in Figure 18-3. 


Figure 18-3 Case Bar Displayed on the Incidents Page 


Cisco SYSTEMS 


[ Cases | 
=) INCIDENTS | CS-MARS Local Controller: pluto/pluto v4.1 Login: Local: Administrator (pnadmin) :: 8 
Select Case:[No Case Selected. SsSs~—CSsSS 
® 
o 
¢ 
Click Hide Case Bar. 
The Case Bar no longer appears on all tabs, as shown in Figure 18-4. 
Figure 18-4 Case Bar Hidden on the Incidents Page 
Cisco Systems 
SUMMARY [INCIDENTS | QUERY / REPORTS | RULES || MANAGEMENT || ADMIN || HELP 
=) INCIDENTS | CS-MARS Local Controller: pluto/pluto v4.1 Login: Local: Administrator (pnadmin) :: u 
Show Case Bar 
Cases Case ID: Show o 
Oo 
al [al a — _ = 
Case ID Status Owner Summary Created / Updated bod 
Displaying the Case Bar 


To Display the Case Bar, follow these steps: 


Navigate to the Cases subtab (Incidents > Cases) as shown inFigure 18-4. 


Click Show Case Bar 
The Case Bar, as shown in Figure 18-3 now appears on all pages. 


Create a New Case 


Step 1 
Step 2 


To create a new case, perform the following procedure: 


Display the Case Bar as described in the section, Hide and Display the Case Bar. 


Click New Case. 
The Add a New Case Dialog box appears, as shown in Figure 18-5. 
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Figure 18-5 Add a New Case Dialog Box 


y [LC: pluto/pluto] Create New Case - Microsoft Internet Explorer ; = {oj x/ 
~ 


Cisco SYSTEMS 


4ug 25, 2005 10:38:28 4M PDT 


Local Controller: pluto/pluto v4.1 Login: Local: Administrator (pnadmin) :: 


Add a New Case 


[Yellow | [assigned | Local: Administrator (pnadmin) Example Case 


| | 


Create New Case 


Copyright ¢ 03, 2005 Cisco Systems, Inc, Feedback 
served, 


All rights 
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| 
Step3 Select a severity color, change the state from new to assigned if appropriate, select the owner, replace 
the default summary name (default is New Case). 
Figure 18-5 shows a case with case summary of Example_Case, assigned to the administrator with a 
yellow priority color (default is Green). 


Step4 Type or paste any annotations into the text space. 


Step5 Click Create New Case. 
The newly created case is numbered and becomes the current case displayed in the Case Bar as shown 
in Figure 18-6. 


Figure 18-6 Case Bar Shows a Newly-Created Case as the Current Case 


Cisco Systems 


SUMMARY [REBERA| query / nevonrs RULES || MANAGEMENT || ADMIN |] HELP 


& INCIDENTS | CS-MARS Local Controller: pluto/pluto v4.1 Login: Local; Administrator (pnadmin) ¢: | Logout | ti | Activate 


Current Case: C:210497 (New) Example Case & 
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Proceed to the section Add Data to a Case for steps on how to combine various data into a single case. 


Edit and Change the Current Case 


Editing the Current Case 


To edit the Current Case complete the following procedure: 
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Step 1 


Step 2 
Step 3 
Step 4 


Step 1 
Step 2 


Step 3 


Display the Case Bar and click More. 
The Case Bar Expands to expose the editing options, as shown in Figure 18-7. 
See the section Hide and Display the Case Bar for procedures to display the case bar. 


Figure 18-7 Expanded Case Bar 


Current Case: €:120497 (New) Example Case 
[Yellow i] [New [=] [Local: administrator (pnadmin) EI [Example Case 


Deselect Case Submit 
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Change the severity, status, owner, or summary of the case as required. 
Add an annotation in the text box as required. 


Click Submit 


Deselecting the Current Case 
To replace the Current Case case with another, complete the following procedure: 


Expand the Case Bar as explained in the previous procedure. 


Click Deselect. 
The Case Bar drop-down list displays No Case Selected. . . as shown in Figure 18-4. 


To select a different Current Case, select a case from the Case Bar drop down list. 


Add Data to a Case 


Step 1 


Step 2 
Step 3 


To add data to a case, complete the following steps: 


Select the Current Case. See the section Edit and Change the Current Case for procedures on selecting 
the Current Case. 


Navigate to the page to be captured in the case. In the example, the Query page is selected. 


Click Add this. . . on the Case Bar. 


Figure 18-8 Case Bar Add Button 


Cisco Systems 


SUMMARY || INCIDENTS [Query /reronis | RULES || MANAGEMENT || ADMIN || HELP 


[Query |[ Batch Query |[ Report [Hig 29, 2005 6:52:16 PM POT | 


= QUERY / REPORTS | CS-MARS Local Controller: pluto/pluto v4.1 Login: Local: Administrator (pnadmin) +; | Logout | tt | Activate 


Current Case; C:110497 (New) Example Case & Add This Report More... 


43450 


1 
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Step 4 


Generate and Emaila Case Report Mi 


To verify that the selected data was added to the case, click the case ID number in the Case Bar to display 
the View Case page. 

In the example shown in Figure 18-8, the selected report should appear in the Reports section of the 
View Case page. A partial View Case page is shown in Figure 18-2. 


Generate and Email a Case Report 


S 


You can generate a case report of the case data and email the report to any MARS user group or 
individual user account. The email event is logged in the case history listings on the View Case page. 


To add a new user account or user group, see “Create a New User—Role, Identity, Password, and 
Notification Information” section on page 22-10. 


Note 


Step 4 


Step 5 


Make sure that the MARS email server is configured. See “Configure the E-mail Server Settings” section 
on page 22-4 for further information. 


To generate a case report and to email it, follow these steps: 


Select a case from the Cases page or from the Case Bar dropdown list. 
Click the Case ID number to navigate to the View Case page. 


Click the check box in an item’s Include field to select or deselect that item for inclusion in the 
Case Document. By default, all items are selected. 


Click Show Include to show only those items selected for the Case Document. Show Include does not 
function for cases created in Cisco Security MARS version 4.1.1. 


Click View Case Document at the bottom of the View Case page. 
MARS generates and displays the case report. 
Click Email Case at the bottom of the report page. 


The Case Email dialog box appears, as shown in Figure 18-9. 
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Figure 18-9 Case Management Email Dialog Box 


Cisco SYSTEMS 


Standalone: LC27 v4.2 Login: Administrator (pnadmin) :: 


Choose Where to Email Case Information 


Email Subject: [Case Doc: C:126597 (New) New Case 
Select All User Groups v | [Search 
| Admin 
0 Notification 
Operator 
Remove DD rT e 
0 Security Analyst 


190151 


Cancel Submit 


Step6 = Click the check box of the user groups or individual users you want to receive the Case Document, then 
click << Add. 


Tip Select All Users from the dropdown menu to display all individual user accounts. 


The selected recipients appear in the left-hand area of the dialog box. 
Step7 Click Submit to send the Case Document to the recipients. 


The email is sent and the case history is updated to show the email event as the lastest item of the case 
history. 
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Incident Investigation and Mitigation 


An incident is a chain of events that are correlated by a rule to signal an attack upon your network. 
MARS simplifies and expedites the detection, mitigation, reporting, and analysis of the incident. The 
Network Summary dashboard and the Incident pages help to detect recent incidents and show the rules 
and the events that compose them. Mitigation refers to the ability of the MARS to isolate the attacking 
and compromised network devices by identifying and configuring enforcing devices that act as choke 
points in the network. Queries and reports reveal the scope of a problem and gather data for analysis and 
regulatory compliance. All this information can be captured in a case report with Case Management and 
escalated to the relevant personnel. 


Incidents Overview 


An attack can consist of a reconnaissance activity (for instance, a port scan), followed by a penetration 
attempt (such as, a buffer overflow), and followed by malicious activity on the target host (for example, 
a local privilege escalation attack or the installation of backdoors). 


An incident, which is generated by a Local Controller, collects the interesting events that constitute an 
attack scenario and uses rules to describe them. MARS provides you with pre-defined, system 
rules—which you can fine tune—and gives you the ability to create your own rules. 


Incidents are sub-divided into instances to make it easier for you to investigate the attack scenario. Each 
instance alone is a full attack scenario. 


For example, if your network is probed for a DoS attack and then attacked, a rule fires when it sees the 
follow up attack. The incident displays the instances of this attack. 
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Figure 19-1 


Incident ID: 429 


A DoS probe followed by a DoS attack 


3 & 


Offset|Firing Event /|Event Type |Source IP/Port 
Session / 
Incident ID 


Instance 2 


3 $:45754259, 
1:42998483 &, 
1:42998484 @ 


instance 3 
1 
1 S:45775179, 


1:42998480 AX, 
1:42998481 Bf, 
1:42998483 &, 
1:42998487 Bf, 
1:42998490 4X, 
1:42998492 Bf, 
£:42998493 &&, 
1:42998495 AY 


The Incidents Page 


[1906920] 
Net Flood 
TecP [a] 


Total: 5 


[1906910] 
Net Flood 


upp [a] 


10.4.17.4 [a] 


[1905037] 
Www SGI 
MachinelInfo 
Info Leak 


[1905110] 
Www SuSE 
Installed 
Packages 
Info Leak 


[a] & 


10.1.1.21 [4) 


10.1.1.21 [g] 
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Click the Incidents tab to navigate to the Incidents page. The Incidents page displays recent incidents. 


Incidents are collections of events and sessions that meet the criteria for a rule, each having helped to 
cause the rule to fire. An incident’s duration only includes the events that contributed to the incident 


firing. 
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The Incidents Page 


Figure 19-2 Incidents Navigation 
Incident ID Event Type Matched Rule Action Time Path |Cases 
 1:347918013@' Deny connection - no xlate[g] System Rule: Client Exploit - Sysbug Trojan[g) 5 EVE 
C 1:342595342g7 Sudden ingrease of traffic System Rule: DoS: Network - Attempt[a] 2D FAIES 
to a pi D 
C 1:347917458 285 Pee login System Rule: Password Attack: System - Attempt[a] : M PI 0G Bal Pren ey: 
co 
a 
t+ 
1 |The Incident ID— Link to the Incident Detail |2  |Incident Severity Icon 
page. 
3 |The events that compose the Incident— 4 |Query icon—Link to the Query page and 
Launches the Event Type Details popup populates the corresponding query field with 
window. the item. 


5 /Therule that fired to create the incident. Links |6 |Time range of the incident. 
to the rule page to display the details of the 
rule. 


7 =|Launches the Incident Path and Incident 8 Link to the View Case page 
Vector diagrams Click to query on the 
matched rule 


The Incident page’s table: 
e Incident ID 
An incident’s unique ID. 
e Severity 
Low (green), medium (yellow), and high (red) icons. 
e Event Type 
The normalized signature sent from the reporting devices. 
e Matched Rule 
The rule whose criteria were met. 
e Action 
The description of the notification taken when this rule fires (epage, email, etc.) 
e Time 
A single time or a time range (see Time ranges for Incidents, page 19-4 for more information) 
e Incident Path 
The icon that takes you to the incident’s path diagram. 
e Incident Vector 


The icon that takes you to the source, event type, and destination diagram. 


| 78-17020-01 


User Guide for Cisco Security MARS Local Controller | 


Chapter 19 Incident Investigation and Mitigation | 


HZ Incident Details Page 


Time ranges for Incidents 


The time column displays both single entries for time (Sep 6, 2003 12:09:54 PM PDT), and time ranges 
(Sep 6, 2003 12:06:43 PM PDT - Sep 6, 2003 12:06:47 PM PDT). 


A single time tells you that all of the firing events were received in the same second. The duration of the 
incident includes only events that have fired that incident. 


Incident Details Page 


Clicking the Incident ID takes you to its Incident Details page. The Incident Details page is rich in 
information and information gathering tools. This page answers questions, such as who did it, what event 
types happened, when it happened, and to whom it happened. 


Figure 19-3 The Incident Details Page 


Cisco Systems 


SUMMARY || INCIDENTS |) QUERY / REPORTS || RULES || MANAGEMENT || ADMIN || HELP 


Incidents || False Positives || Cases 


&? INCIDENTS | CS-MARS Local Controller: pluto/pluto v4.1 Login: Local: Administrator (pnadmin) +; | Logout | i! | Activate 
200982691 Show 
Shov 
Rule Name: aLcTest Status: Active 
Action: None Time Range: 9h:10m 
Description: aLcTest 
Offset|Open ( [Source 1P|Destination IP Service Name Event Device Reported User Keyword Severity Count] ) Close|Operation 
1 ANY ANY ANY ANY cherry Wall ANY ANY ANY 1 
Incident ID: 2009826918 [aJBx Expand All Collapse All 
Offset|Session / Event Type Source IP/Port Destination Protocol| Time Reporting Reported [Path / False 
Incident ID IP/Port Device User Mitigate _|Positive 
1 Built/teardown/permitted IP ps: 6, 
connection|a Te 2 
1 $:200882690, PIX firewall login failed[aJAX, 10.2.3.33 [@) 40224 [a] 10.4.5.1 [a] 22 [a) TCP Sep 5, 2005 11:20:05 AM PDT cherrywall fa) pix[a) ee) False Positive 
1:20098269188, TCP access requested to the PIX 
7:200982688 & firewall[a]), 
1:2009826894%, TCP or UDP access permitted to the PIX 
1:20098269048 firewall[a}S), 
SSH session disconnected for a 
reason|[al + 
N 
3 
Summary :: Incidents :; Query / Reports :; Rules :: Management :: Admin :; Help Feedback | <p 
= 


On the top of this page are the tools that let you search for Incident and Session ID and view the Matched 
Rule. 


To Search for a Session ID or Incident ID 


Step 1 
Step 2 


Enter the ID into the appropriate field. 
Click the Show button. 
To view a partially hidden rule 


Click the Show button next to the Rule Description. 
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Incident Details Table 


Incident Details Page 


Each row of the Incident Details table represents either a session or the information common to a group 
of sessions. You can see all of the collapsed session information by clicking the plus signs to expand the 
group. You can expand or collapse all of the incident’s information by clicking the Expand All or 
Collapse All buttons. 


Figure 19-4 


Expanding a Row in a Table’ 


Offset|Session / Event Type Source IP/Port Destination Protocol|Time Reporting Reported [Path / False 
Incident ID IP/Port Device User Mitigate Positive 
1 Built/teardown/permitted IP 
connection 
Dffset|Session / Event Type (Source IP/Port Destination IP/Port Protocol] Time Reporting [Reported |Path/  |False 
Incident ID Device User Mitigate _ [Positive 
EE Built/teardown/permitted IP =] Groups: 6, Total: 12 
connection|3] 
1 Built/teardown/permitted IP 0.0.0.0 [a] of 0.0.0.0 (4)  [a) Tcp [a] Sep 5, 2005 11:20:05 AM PDT cherryWall H+] Total 
connection| 
B BuiltYteardown/permitted IP 10.2.3.42 [4] 51893 [4) 10.4.1.20 [a] 18184 [a] TcP [] Sep 5, 2005 11:20:09 AM PDT cherryWall -] Total 
connection| 
1 $:200882703, Built/teardown/permitted IP 10.2.3.43 [@) 52499 (a) 10.4.1.251 [a) 443 [a] TCP [@) Sep 5, 2005 11:20:05 AM PDT cherryWall fal EAL) False Positive 
r2009s2691&, pannection|a)er 
12009826888 
1:20098268928. 
1:2009826908 
Built/teardown/permitted IP 10.4.1,200 [4] 1025 [a] 10.1.1.189 [a] 514 [a] oP Sep 5, 2005 11:20:05 AM PDT cherryWall [+] Total 
connection| 
$:200882688, Built/teardown/permitted IP. 10.4.2.11 [a] 22 [@}_~—«10.2.3.33 [a] 40222 [a) TcP [@) Sep 5, 2005 11:20:05 AM PDT cherrywall fa ie) False Positive 
120098269148, connection|a] 
1:200982688 88, 
1:20098268988 
1:20098269088 
1 Built/teardown/permitted IP 67.416 29.66 [4] 9604 [a] [+] Total: 2 
connection| 
1 $:200882690 PIX firewall login failed [a], 10.2.3,33 fg] 40224 fa) 104.51 a) 22 tcp [@) Sep 5, 2005 11:20:05 AM PDT cherryWall fy pix[a) Ze) False Positive 
£:200982691£8, TCP access requested to the PIX 
£:20098268888, — firewall[a\), 
1:2009826894, TCP or UDP access permitted to the 
1:20098269088 PIX firewall [a)), 
SSH session disconnected for 3 © 
reason(a} a 
+ 
ip) 
Copyright © 2003, 2005 Cisco Systems, Inc Summary !! Incidents !: Query / Reports :: Rules :: Management :: Admin !: Help Feedback vt 
~ 


This high-density information table lets you drill deep into incidents. Click the Query 4) icon anywhere 


on this page to query on a particular criteria. Click the Raw Events 


fs icon for raw events for a particular 


session. You can click the Tune link to tune incidents for False Positives, see The False Positive Page, 
page 19-8 or click the Mitigate link to mitigate an attack. 


Figure 19-5 


U1. 


Incident Table 


Incident ID: 2009826 (EI Expand All Collapse All 
Offset|Session / Event Type Source IP/Port Destination Protocol|Time Reporting Reported [Path / False 
Incident ID Ip/Port Device User Mitigate Positive 
1 Built/teardown/permitted IP 
cannection| 
1 $:200882690, PIX firewall login failed [a], 10,2.3.33 5B) 40224 [g) 10.4.5.1 [a] 22 [g) TOP (a) Sep 5, 2005 11:20:05 AM PDT cherryWall Ga pix[a) C) False Positive 


£:200982691 88, 
#:200982688 8, 
1:2009826894%, 
1:20098269048 


TCP access reguesed to the PIX 
firewall 


firewall|a}), 
SSH a) ‘disconnected fora 


o 


reason|a} 


© 


1 [Incident ID 


TCP or ee access permitted to the PIX 


i 


49) 


Severity icon 


143425 


Path and Incident Vector icons. Launch popup 
windows to display Path and Incident Vector 
diagrams (L2 or L3 attack path information) 


Offset number 


Links to Session and Incident Detail pages of 
all incidents within the session 


Links to the Event Type Details pages 
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7 ‘|Launchs False Positive popup window 8 |Link to the Device Information page 


9 Query icon links to Query page 10 |Click Device icon to launch popup window to 
display raw message information 


11 |Link to the Mitigation Information page 12 |Link to the False Positive Tuning page 


The following information describes some of the fine points of this table. 
e Instances 


Sometimes rows are split into instances. The only relationship among the different instances is that they 
fired the same rule in the same time frame. 


e Session/Incident ID 


This column shows the sessions that contributed to the incident, and the other incidents those sessions 
belong to. 


e Events column 


The Events column shows types of the firing events. Multiple firing events of the same types are shown 
once per session. 


e Time column 


An incident’s duration only includes the events that contributed to the incident firing. 


False Positive Confirmation 


When investigating incidents, you will invariably come across false positive events. In some cases, firing 
events are classified automatically by MARS as system-confirmed false positives and unconfirmed false 
positives. Vulnerability scanning often identifies the false positive events, but at times you must 
investigate events to determine their validity. 


To understand the false positive nomenclature and what tasks you are expected to perform within the 
user interface, we must study the possibilities among three variables surrounding possible attacks: 
legitimate attack, valid target, and attack detected. We examine these differences in Table 19-1. 


Table 19-1 Attack Type Truth Table 


Legitimate Attack Valid Target Attack Detected 
invalid scenario 0 0 0 
False Positive 0 0 1 
invalid scenario 0 1 0 
False Positive 0 1 1 
False Negative 1 0 0 
Attack/Alarm (noise) 1 0 1 
True False Negative 1 1 0 
Intrusion/True Alarm 1 1 1 


Based on the valid cases in Table 19-1, we can clearly distinguish the false positive terminology: 
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e A legitimate attack is an actual attempt by an attacker to gain access to or information about a 
specific host using a known exploit. 


e A valid target is a host that is susceptible to the launched attack. A host can become an invalid target 
if it is properly patched or has some other preventative measure in place, such as a local firewall, 
virus scanner, or intrusion prevention software that guards against the attack. 


e Attack detected refers to whether the monitoring device detected the attack and generated an alarm. 


e A false positive is when the monitoring system generates an alarm for a condition that is benign. In 
this case, there is no legitimate attack, despite the alarm generation. 


e An unconfirmed false positive is one where the monitoring system, based on data not available to 
the reporting device, has determined that an alarm is a false positive. Unconfirmed refers to the fact 
that the administrator must review and accept or reject the assessment of the false positive. 


e A false negative is when the monitoring system fails to detect a legitimate attack. 


e Noise refers to those alarms that are triggered due to attacks against invalid targets. While they can 
represent real attacks, the target cannot be compromised due to preventative measures. Attacks that 
fall within the noise category are of secondary importance in terms of investigation and mitigation. 


e Intrusion identifies a successful attack against the host, where the host is compromised by the 
attacker. 


e A true false negative identifies an intrusion that remains undetected by the monitoring system. 
e A true alarm identifies an intrusion that is detected by the monitoring system. 


When a Local Controller receives an event, it is evaluated against the conditions of the defined rules. If 
the event satisfies the conditions of a rule, then the incident triggers. When an event triggers an incident, 
we refer to that event as a firing event. False positive analysis is performed for such firing events to 
reduce the number of false alarms. 


Using built-in event vulnerability data, learned topology paths, sessionized event data, ACL analysis of 
layer 2 and 3 reporting devices, supporting data from 3"'-party vulnerability analysis (VA) software 
(such as Foundstone and eEye), and information that you provide about hosts, MARS analyzes the firing 
events reported to it determine whether the they hold up to a higher-level review. 


In the case of MARS, a system-confirmed false positive is where, after further analysis, a firing event is 
determined to be invalid. Example system-confirmed false positives include: 


e When an IDS device monitoring the network outside of a firewall reports an attack; however, the 
firewall drops that session as part of its standard access restrictions. Therefore, the attack never 
reaches the target. 


e Cisco Security Agent detects an attack and blocks it. 


An unconfirmed false positive is where, after further analysis, the firing event is believed to be invalid 
primarily due to the attack being against an invalid target. Example unconfirmed false positives include 


e A reporting device reports a valid attack against a host; however, the host is not susceptible to that 
attack because it targets a different operating system. You can reduce these types of false positives 
by employing OS fingerprinting technologies on the reporting devices. 

e A reporting device reports a valid attack against a host’s application; however, the host is not 


susceptible to that attack because it targets a different application. 


e A reporting device reports a valid web attack against TCP port 80, however, dynamic probing 
determines that no services on the target host listen to TCP port 80. 


For unconfirmed false positives, you must manually investigate the alarm and specify in 
Local Controller whether it is an actual false positive. For actual false positives, you should define a drop 
rule for the event. Defining a drop rule does not mean that the event is not stored in the database, you 
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have the option of dropping the event from incident evaluation and either shoring it in the database or 

not. Whether you store the event in the database or not, events matching the event type and target host 
can no longer act as firing events. By refining the event processing in this fashion, MARS frees up your 
time to focus on actual incidents by more accurately correlating events into incidents and reducing noise. 


As part of your operational strategy, you should strive to refine event generation and processing to tune 
out the possibility for false positives. You can perform such tuning at the device level, by refining what 
traffic or action can generate an event, and at the Local Controller level by providing more information 
about your network, such as identifying the operating system of hosts attached to the network segments 
monitored by that Local Controller. 


The False Positive Page 
To navigate to the False Positives page, click Incidents, and click the False Positives sub-tab. 


The False Positives page is where you can see groupings of False Positives. 
You can filter categories by clicking on the Select False Positive drop-down list. Your choices are: 
¢ Unconfirmed false positive type 


For this type, the MARS needs user confirmation to determine if the target host is vulnerable to the event 
type in question. 


e User confirmed false positive type 

For this type, a user has provided confirmation that a firing event is a false positive. 
¢ User confirmed positive type 

For this type, a user has provided confirmation that a firing event is a true attack. 
e System determined false positive type 

For this type, the system has determined that a firing event is a false positive. 


In the False Positives table, you can see how many sessions the false positive has appeared in, the event 
type, the false positive status confirmation icons, the event type information icon, the destination IP and 
its port, the destination IP information icon, its protocol, zone, and you can see the sessions that are 
related to the false positive. 


Figure 19-6 False Positive Table 
Session Count [Event [Destination IP/Port [Protocol |Zone Related Sessions 
192 [1905035] WwW HylaFAX Faxsurvey Command Exec [q] 4, 10.4.17.2 [a] 80 [a] TcP [a] CA Show 
ise} 
g 
1 |Link to the Event Type Details page 2 {Query icon links to the Query page and 


automatically populates the corresponding 
Query field 


3 False Positive type and severity icon 4 Launches the Security Device Information 
popup window 


5 Launches Port Information popup window 6 Launches False Positive Sessions Details 
popup window 
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The following table shows false positive status confirmation and severity icons:Tuning False Positives 


Icon Description 
aAw Low, medium, and high severity false positives that require 
e confirmation. 
a, Low, medium, and high severity user determined false positives. 
® & a 
Low, medium, and high severity system determined false 


® & bl positives. 


From the Incidents page or the False Positives page, you can tune false positives — to verify if they are 
true or false. 


To Tune a False Positive 


Step 1 
Step 2 
Step 3 


Step 4 


Click one of the Confirm False Positive icons. @) A, BJ 
On the False Positive Confirmation page, review the information. 


If you decide that the event type is a false positive, click the Yes radio button, and follow the steps in: 
To Tune an Unconfirmed False Positive to False Positive, page 19-9. 


If you decide that the event type is a true positive, click the No radio button, and follow the steps in: To 
Tune an Unconfirmed False Positive to True Positive, page 19-9. 


To Tune an Unconfirmed False Positive to False Positive 


Step 1 
Step 2 


Step 3 
Step 4 
Step 5 


After you determine that a false positive is false, and you have clicked the Yes button, click Next. 


On the next page, decide whether or not you want MARS to keep this event type in the database by 
selecting the appropriate radio button: 


- Dropping these events completely (that stops logging those events) 
- Log to DB only (that logs the events to the DB) 
Once you have decided, click the Next button. 
On the next page, carefully review the information for the false positive and the new rule. 


When you are ready to commit this new information to the appliance, click the Confirm button. 


To Tune an Unconfirmed False Positive to True Positive 


Step 1 
Step 2 


After you determine that a false positive is true, and you have clicked the No button, click Next. 


Make a final confirmation that this is a true positive, and click the Confirm button. 
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To Activate False Positive Drop Rules 


Mitigation 


wy 


After you have completed tuning false positives, click Activate to immediately implement the changes. 


Mitigation refers to the action of limiting an attacking network element’s access to the network by 
modifying the configuration of an enforcement device, usually a switch, router, or firewall. CS-MARS 
can perform the following actions related to mitigation: 


e Identify attacking and compromised hosts 


e Plot Layer 2 and Layer 3 topology of the affected network segment to identify mitigation points and 
enforcement devices 


e Recommend configuration commands for Layer 2 and Layer 3 enforcement devices 


e Push (that is, download) recommended configuration commands to supported Layer 2 devices 


With Telnet, SSH, or SNMP access to switches and routers, CS-MARS can recommend and push 
mitigation configurations to enforcement devices, as well as generate interactive topology and incident 
path diagrams. Without Telnet, SSH, or SNMP access, some mitigation information can still be obtained 
from Cisco switches running specific IEEE 802.1X Port Based Network Access Control protocol 
configurations, but recommended mitigation commands must be configured manually on the 
enforcement devices. See Layer 2 Path and Mitigation Configuration Example, page 19-17 for further 
information and procedures for configuring Layer 2 devices to receive CS-MARS mitigation commands. 
Static and Dynamic Network Information 


Topology information obtained from access to relatively permanent Layer 2 and Layer 3 devices is called 
Static Information in the HTML interface. Dynamic Information refers to frequently changing 
information such as host names, or DHCP-leased IP addresses obtained through devices or agents that 
report dynamic events, such as 802.1X access control configurations, the Cisco Security Agent, or other 
security suite software. The CS-MARS can determine a mitigation point and an enforcement device if a 
Cisco 802.1X-enabled switch is running DHCP-snooping with RADIUS authentication through a Cisco 
Access Control Server (ACS). When a DHCP-snooping transaction is completed, the switch sends a log 
message to the ACS. The ACS logs are sent to the CS-MARS to report the Source IP address, user name, 
connection start and stop times, physical interface, and MAC address of each 802.1X client. Because 
802.1X clients are often mobile, remember that 802.1 X mitigation actions can occur only when the 
attacking host is currently connected to the network. 


Note 


For some 802.1X switch configurations, it is not possible for CS-MARS to determine the correct 
physical interface to which to push a mitigation command. This occurs for switches, such as the Cisco 
Catalyst 3550 Multilayer switch, where a FastEthernet and a Gigabit Ethernet port can have the same 
module/port designation (for example, 0/1). Because CS-MARS receives only the module/port 
information from the Cisco ACS logs, it cannot identify the specific port to mitigate. The following 
message appears in these circumstances: 

No mitigation possible. Enforcement device exists but interface names conflict. Determine 
appropriate interface and mitigate manually. 
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802.1X Mitigation Example 


In this procedure, an incident is observed on the Network Summary page, as shown in Figure 19-7, and 
mitigated through 802.1X network mapping. 


Prerequisites for Mitigation with 802.1X Network Mapping 
To perform mitigation with 802.1X network mapping with CS-MARS, the following prerequisites are 
required: 


¢ Cisco switch running Cisco CatOS or IOS and configured with IEEE 802.1X Port Based Network 
Access Control protocol 


e The switch Reporting IP address must be configured on the CS-MARS Security and Monitoring 
Information page (Admin > Security and Monitor Devices). 


e¢ Cisco DHCP-Snooping enabled on the switch 


e The switch performs Remote Access Dial-In User Service (RADIUS) authentication, authorization, 
and accounting through a Cisco Access Control Server (ACS). 


e The Cisco ACS is running pnLogAgent to send logs to CS-MARS 
e The Cisco ACS is configured to log Update (Watchdog) packets 


Figure 19-7 Summary Page Displaying Incident to Mitigate 
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Procedure for Mitigation with 802.1X Network Mapping 


Step 1 Click the Incident ID of the recent incident to Mitigate. 


Step2 Click on the Incident ID to display the session summaries, shown in Figure 19-8. 


User Guide for Cisco Security MARS Local Controller 
| 78-17020-01 19-11 | 


Chapter 19 Incident Investigation and Mitigation | 


HI Mitigation 


Figure 19-8 Incident Detail Page Displaying Red Mitigation Icon 
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Step3 = Click the red path information icon in the Path/Mitigation column. 


The Mitigation pop-up window appears, with any possible Static topology and mitigation information, 
as shown in Figure 19-9. 


CS-MARS recommends enforcement devices and mitigation commands. For static information, if the 
network is entirely discovered and CS-MARS has command level access to a Layer 2 enforcing device, 
the Push button appears red, otherwise it is gray. In Figure 19-9, CS-MARS does not have sufficient 
static information to identify a Layer 2 enforcement device, but can suggest mitigation commands for 
discovered Layer 3 devices (Cisco PIX firewall, and a Cisco router). Layer 3 mitigation commands must 
be configured manually on the Layer 3 devices. 
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Mitigation 


Figure 19-9 Path Information Pop-up Window 
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Push | [ cancel 


Click Dynamic Info to view Layer 2 mitigation recommendations derived from 802.1 X configurations. 


The Dynamic Mitigation window appears with host name, IP address, MAC address, and connection 
status as shown in Figure 19-10. 
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Step 5 
Step 6 
Step 7 


Figure 19-10 Dynamic Mitigation Information 


Cisco SYSTEMS 


Local Controller: pnmars/LC10.1.1.189 v4.1 Login: Local: Administrator (pnadmin) :: 


cation information reported by 444 servers and network devices as a result of enforcing 
Admission Control etc. 
% 


Static info Dynamic Info 


Dynamic information utilizes current he 
mechanisms such as 802,1x, Cisco 


Host IP Address: 20,1.1.210 

Host MAC Address: 00-11-11-31-e3-48 
Cisco ACS NAS IP: 10,1.1.243 

Cisco ACS NAS Port: 313 

AAA User Name: cisco 


Enforcement Device: 


Enforcement Device (Device Name:Module/Port)|Start Time End Time|Update Time 
dot1x_switch:3/13 Oct 3, 2005 2:18:53 PM PDT Present Oct 3, 2005 2:18:53 PM PDT 


Recommended Policy/Command 


oF configure t 
interface 3/13 
shutdown 
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Review the enforcement device. 
Review the Recommended Policies/Commands. 


Click Push to download the recommended mitigation command to the enforcement device. The 
mitigation confirmation dialog appears, as shown in Figure 19-11. 

If the Push button is gray, the mitigation command must be manually configured on the enforcement 
device. 


& 


Note The Push button is red and functional when the 802.1X target host is present on the network, 
and CS-MARS has command access to the enforcement device otherwise, it appears gray and is 
not functional. 
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Figure 19-11 Mitigation Confirmation Dialog 
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Download Mitigation Command 
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Step8 Click Yes to confirm. 


Display Dynamic Device Information 


To display current, session, and all historical information for an IP address on an 802.1X connection, 
follow these steps: 


Step 1 Click on the Incident ID to display the session summaries as shown in Figure 19-8. 


Step2 Click on the Source IP/Port or Destination IP link of a session. 
When examining an attacking host, the Source IP address is more relevant. 


Step3 The current connection information pop-up window appears to display any static connection 
information. 


Step4 = Click Dynamic Info to display current connection information, as shown in Figure 19-11. 
Dynamic information can be derived from 802.1X configurations, Cisco Security Agents, or from other 
security software suites. The current connection information is the most recent network information 
available for the selected IP address. 


Step5 Click Session to display the connections related to the specific session, a shown in Figure 19-13. 
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Step 6 


Figure 19-12 Dynamic Information—Current Connection Status 
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Click All to display the entire dynamic information for the specified IP address, as shown in 


Figure 19-13. 


Figure 19-13 Dynamic Information History of a Specified IP Address 
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Click the Push button if available or mitigate from the device. If you select the push button, a 


confirmation screen appears. 


To mitigate a device of Access Type SNMP you must have the SNMP Read/Write Community String. 


Click the Yes button to confirm the mitigation command and have it take effect. 
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Virtual Private Network Considerations 


Currently, MARS cannot display accurate Path/Mitigation information or compute the complete route of 
an attack originated by a host with a source IP address on a virtual private network (VPN). MARS can 
identify the attacking host if the VPN IP address of the host was supplied by a Cisco 3000 Series VPN 
Concentrator configured as a MARS reporting device. 


Note You must be able to recognize from your knowledge of your network that the IP address of the attacking 
host is an IP address allocated to a VPN. 


To identify a host attacking from a VPN, perform a query of “Cisco VPN User connected/disconnected” 
events for the Cisco VPN Concentrator device. The attacking host name or next network element is 
disclosed in the raw messages of the events. 


Layer 2 Path and Mitigation Configuration Example 


This section provides a starting point for configuring MARS to perform Layer 2 (L2) path analysis and 
mitigation using a Cisco switch. It contains the following sections: 


- Prerequisites for Layer 2 Path and Mitigation, page 19-17 

- Components Used, page 19-17 

- Network Diagram, page 19-18 

- Procedures for Layer 2 Path and Mitigation, page 19-19 

- Add the Cisco Catalyst 6500 with SNMP as Access Type (Layer 2 only)., page 19-20 
- Add the Cisco 7500 Router with TELNET as the Access Type, page 19-21 

- Verify the Connectivity Paths for Layer 3 and Layer 2, page 19-22 

- Perform Mitigation, page 19-26 


Prerequisites for Layer 2 Path and Mitigation 


e You need to have the SNMP community strings and IP addresses for the Layer 2 switches and 
routers. 


e You must have STP (Spanning Tree Protocol) configured correctly on the switches. 


Components Used 


e a Cisco Catalyst 5000 with SNMP access enabled 
e a Cisco Catalyst 6500 for Layer 2 with SNMP access enabled 
e aCisco 7500 Router with SNMP or TELNET access enabled 


e a MARS running software Version 2.5.1 
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Network Diagram 


This section uses the network setup shown in the Figure 19-14. 


Figure 19-14 Network Setup 
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Mitigation uses the Layer 2 path data obtained via SNMP or Telnet protocol to download a mitigation 
command from the MARS to the device. The Layer 2 path is based on MAC addresses, the Layer 2 
forwarding table, and the Layer 3 path. MAC addresses and the Layer 2 forwarding table are obtained 
using SNMP. 


To make the Layer 2 path and mitigation work correctly: 


e The associated routers must be discovered via SNMP or a combination of SNMP and Telnet, 
including the MSFC module in the Catalyst switch. 


e The SNMP community string is necessary for L2 switches to be discovered 


Note 


L2 devices must be added manually; there is no automatic discovery for these devices. Make sure all the 
L2 devices (switches) have the SNMP RO community strings specified in the web interface, even if the 
access type is not SNMP. The SNMP RO community string is always required on Layer 2 devices for L2 
mitigation. 


e Ifthe switches are interconnected, make sure STP (Spanning Tree Protocol) is enabled and 
configured on them. 
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Layer 2 Path and Mitigation Configuration Example Hi 


For example, given a topology such as the one in the preceding figure, follow these instructions to 
discover these devices. 


Add the Cisco Catalyst 5000 with SNMP as the Access Type. 


Step 1 


Step 2 
Step 3 
Step 4 


Step 5 


Click Admin > Security and Monitor Devices > Add. 


Figure 19-15 


Configure Cisco Switch CatOS 


Device Discovery-Cisco Switch-CatOS ANY 


Supervisor Module 


co Switch-Catos 


ANY 


porting IP (the IP address where events originated from) to ensure that the system processes the events. 
s a required field, 


> *Device Name: 


> *Access IP: 


> *Reporting IP: 


> *Access Type: 


Login: 


Password: 


Config Path: 


File Name: 


Enable Password: 


SNMP RO Community: 


MySNMPCommstr 


Cancel Submit 
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Test Connectivity 


From the Device Type drop-down list, select Cisco Switch-CatOS ANY. 


Enter the Device Name of the switch. 


Enter the Access IP address and Reporting IP address (the IP address of the device as it appears to the 
MARS) of the switch. The Reporting IP address is usually the same as the Access IP address, but if you 
are using FTP as Access Type, it must be a different IP address. The Reporting IP address is required 
if the device is sending syslog data to the MARS 


From the Access Type drop-down list, select SNMP or TELNET. Note that which fields need to be 
completed, along with which you can complete, depend on which Access Type you select. 


SNMP: 


- For the Login ID, enter the user name and Password needed to access the switch. 


- For Enable Password, enter the password to get into Cisco enable mode. 
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- Enter itt SNMP RO Community. 
TELNET: 
- For the Login ID, enter the user name and Password needed to access the switch. 
- For Enable Password, enter the password to get into Cisco enable mode. 
- Enter itt SNMP RO Community. 
Step6 Click the Test Connectivity button to have the MARS discover the device. 
Step7 Click the Submit button. 


Add the Cisco Catalyst 6500 with SNMP as Access Type (Layer 2 only). 


Step1 Click Admin > Security and Monitor Devices > Add. 


Figure 19-16 Configure Cisco Switch CatOS 


Device Discovery-Cisco Switch-CatOS ANY 


Note: 
1. Enter the reporting IP (the IP address where events originated from) to ensure that the system processes the events, 
2. * denotes 4 required field. 


Device Type: | Cisco Switch-CatOS ANY v 


Supervisor Module 


> *Device Name: 


> *Access IP: 


=> *Reporting IP: 


> *Access Type: 


Login: 
Password: 
Enable Password: 


Config Path: 


File Name: 


SNMP RO Community: |mySnmMPCommStr 


Test Connectivity Cancel Submit 
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Step2 From the Device Type drop-down list, select Cisco Switch-CatOS ANY. 
Step3 Enter the Device Name of the switch. 


Step4 —_ Enter the Access IP address and Reporting IP address of the switch. The Reporting IP address is 
usually the same as the Access IP address. 


SNMP: 


- For the Login ID, enter the user name and Password needed to access the switch. 
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- For Enable Password, enter the password to get into Cisco enable mode. 
- Enter itt SNMP RO Community. 
TELNET: 
- For the Login ID, enter the user name and Password needed to access the switch. 
- For Enable Password, enter the password to get into Cisco enable mode. 
- Enter itt SNMP RO Community. 
Step5 Click the Test Connectivity button to have the MARS discover the device. 
Step6 Click the Submit button. 


Add the Cisco 7500 Router with TELNET as the Access Type 


Step1 Click Admin > Security and Monitor Devices > Add. 


Figure 19-17 Configure Cisco IOS 12.2 


Device Discovery-Cisco IOS 12.2 


Note; 
1, Enter the reporting IP (the IP address where events originated from) to ensure that the system processes the events, 
2. * is denotes a required field. 


Device Type: | Cisco IOS 12.2 v 


> *Device Name: 


MainRouter 


> *Access IP: 10) ffi 41 41 
> *Reporting IP: re | aE | {a | 
> *Access Type: TELNET ¥ 

Login: myuserid 

Password: ecccccccce 

Enable Password: eocee 

Config Path: 

File Name: 

SNMP RO Community: |mySsnmPCommstr 
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Test Connectivity | Cancel | | Submit 


Step2 | From the Device Type drop-down list, select Cisco Switch-IOS 12.2. 
Step3 Enter the Device Name of the switch. 


Step4 —_ Enter the Access IP address (optional) and Reporting IP address of the switch. The Reporting IP 


address is usually the same as the Access IP address, but if you are creating an FTP device it must be a 
different IP address. 


If you have entered an Access IP address, from the Access Type pull-down menu, select FTP: 
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FTP: 
- For the Login ID, enter the user name and Password needed to access the switch. 
- For Config Path, enter the path of the configuration file on the FTP server. 
- For File Name, enter the switch configuration file name on the FTP server. 


- Enter its SNMP RO Community. 


- For the Login ID, enter the user name and Password needed to access the switch. 
- For Enable Password, enter the password to get into Cisco enable mode. 


- Enter its SNMP RO Community. 


- For the Login ID, enter the user name and Password needed to access the switch. 
- For Enable Password, enter the password to get into Cisco enable mode. 
- Enter itt SNMP RO Community. 
TELNET: 
- For the Login ID, enter the user name and Password needed to access the switch. 
- For Enable Password, enter the password to get into Cisco enable mode. 
- Enter itt SNMP RO Community (mandatory). 
Step5 Click the Test Connectivity button to have the MARS discover the device. 
Step6 Click the Submit button. 


Verify the Connectivity Paths for Layer 3 and Layer 2 


Once you have a session, you can view the Layer 3 and Layer 2 topology paths. There are several ways 
to obtain a session. 


e To view sessions that are part of an Incident: 


Step 1 Click the Incidents tab to navigate to the Incidents page. Click an Incident ID of an incident you want 
to view (in this example we use Incident number 356120290). The Incident Details screen appears. 
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Figure 19-18 Incident Details screen 


<G Matched Rule: System Rule: Server Attack: RPC - Success Likely 


Description: This correlation rule detects specific attacks on RPC services on a host followed by suspicious acti... 
Offset|Open Source: Destination Service |Event Device|Severity|Counts|Zone a] Action/Operation|Time-range 
€ Name Close 
ANY ANY ANY System Rule: ANY ANY 1 ProtegoHQ Ohh:30mm:0ss 


Server Attack: 
RPC - Success 
Likely 


Incident ID: 356120290 gf EI Escalate Expand All Collapse All 
Session in Feo (decane ko I yr | at Ibe (cma rs= 2c [ctf ete Event Type Source IP/Port Destination Protocol Reporting False 
Incident ID in Feo (decane ko I yr | at Ibe (cma rs= 2c [ctf ete Device Positive 


: a : | | 


1:356120249 B, 
1:356120250 @, 
1:356120253 £¥, 
1:356120254 Bf, 
1:356120255 Bf, 
1:356120257 4, 
1:356120258 Bf, 
1:356120261 4, 
1:356120262 @, 
1:356120266 &f, 
1:356120267 BT, 
1:356120269 &, 
1:356120274 @, 
1:356120277 Bf, 
1:356120278 GT, 
1:356120279 &, 
1:356120282 &, 
1:356120283 4X, 
1:356120287 @, 


1:356120290 
2 $:372468056, Windows RPC 101,252,250 (4) 3967 [a] 65.54.143.118[4] 135 [a] TCP [a] Jun ac ProtegoH@ firewall (q) fay [J Tune _— Mitigate 
1:356120290 Gf, DCOM ated 
1:356120293 By Overflow [a] Br, 1:31:40 
Windows PM PDT 


SMB/RPC NoOp 
Sled 


3 $:372468056, Windows RPC 10.1.252.250 [a] 3967 [a] 65.54,143.118[4] 135 [a] TCP [a] pa 21, ProtegoH@ firewall [q) fas Tune Mitigate 
£:356120290 Ef, DCOM 2004 
1:356120293 gf Overflow [a] Br, 1:31:40 
Windows PM PDT 
SMB/RPC NoOp 
Sled 
5 
a. 2 


10.4.14.2 [a | Total: 3 
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In the Incident Details screen, in the same row as the Event Type you want to examine (in this example 
we use Windows RPC DCOM Overflow), click the graph icon under the Graph column to view the 
topology paths. 


¢ To view sessions by performing a Query: 


Click QUERY / REPORTS and submit a query using the appropriate query criteria. Note that in our 
example, we limit the scope of the query so it runs faster. In the following Query Event Data screen we 
use the result format All Matching Sessions and query events from Source IP 10.1.252.250 and 
Destination IP 65.54.153.118 over the last 10 minutes. 


| 78-17020-01 


User Guide for Cisco Security MARS Local Controller gy 


Chapter 19 _ Incident Investigation and Mitigation | 


HH Layer 2 Path and Mitigation Configuration Example 


Figure 19-19 Query Event Data screen 


Query Event Data 
Click the cells below to change query criteria: 


Query type: Sessions ranked by Time, Ohh:10mm:0ss 


[Source IP [Destination IP Service |Events [Device |Severity |Zone [Operation [Rule [Action [Reported User 
H-10,1,252,250 H-65,54,153,118 ANY ANY ANY ANY ANY None ANY ANY ANY 


Keywords: [ None ] [Edit] 


Apply 


Result Format: All Matching Sessions 


Order/Rank By: | Time ¥ 


Filter by Time: 


@ Last:|o Days|0 Hrs|10 |Mins 


C Start:| 2004 vill June ¥ || 22 v)fts_]Hrs[38__|mins 
End: | 2004 || June v||22 v|[te_Jrrsf4s__|mins 
™ Real Time 


Use Only Firing Events: [— 


Maximum rank returned: 
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Apply 


Step2 After you Apply changes to and Submit your query, the Query Results screen appears. 


Figure 19-20 Query Results screen 


Query Event Data 


Click the cells below to change query criteria: 


Query type: Sessions ranked by Time, Ohh:10mm:0ss 


Source IP Destination IP Events |Device |Severity {Zone |Operation |Rule |Action |Reported User 
H-10,1.252,.250 H-65, 54,153,118 ANY ANY ANY ANY ANY None ANY ANY ANY 
Keywords: [ None ] [Edit] 
Save As Report Save As Rule Clear Apply Submit 
Query Results EAE Expand All | Collapse All 
Session {/ |Events Source IP/Port Destination IP/Port |Protocol|/Time |Zone Reporting|Graph|False Mitigation 
Incident ID Devices Positive 
Built/teardown/permitted 10.1.252.250 [a] 65,54.143,118 [4] 
IP connection Total: 5 


$:381559066 Windows RPCDCOM —10.1.252.250 [a] 1421 [a] 65.54.143.118 [a] 80 [a] TcP [a] Jun 22, ProtegoHQ firewall [g) [&] © Tune ‘Mitigate 
Overflow 2004 


com 
5:31:15 
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Step3 = In the Query Results screen, in the same row as the Event Type you want to examine (in this example we 
use Windows RPC DCOM Overflow), click the icon under the Graph column to view the topology paths. 


The first topology path to appear is the Layer 3 topology graph: 
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Figure 19-21 Layer 3 topology graph 


Topology Path Graph 


Layer 3 Path | Layer 2 Path | | Full Topology 


oma 


aw 
Oca 65.54.143.118 


n-10.4)4.0/24 


a4 


H-10.1.252.250 
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Under Topology Path Graph, click the Layer 2 Path button to view the Layer 2 topology graph: 
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Figure 19-22 Layer 2 topology graph 


Topology Path Graph 


Layer 3 Path | | Layer 2 Path | | Full Topology 


H-10.19252.250 


n-10.4.4.0/24 


— 
PP imeiien 


i] 
65.54.143.118 
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Perform Mitigation 


Once you identify the compromised host (in this example, 10.1.252.250 connected to CatSw), it is 
critical to prevent it from attacking other hosts in the same subnet or other parts of the network. The 
MARS provides one-click mitigation that lets you isolate the compromised host from the rest of the 
network. 


To perform mitigation, perform these steps: 


Step1 On the Incident Details screen, click the Mitigate link that corresponds with the Session or Event Type 
you want to mitigate (in this case, Windows RPC DCOM Overflow). The Mitigation Information 
screen appears. 
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Figure 19-23 Mitigation Information screen 


ay INCIDENTS | Login: Administrator, Administrator (pnadmin) :: Jun 14, 2004 3:50:57 PM PDT :: 


Mitigation Information 


Enforcement Devices| Enforcement Device - Suggested 


CatSw (L2) (suggested) 
KittenSw (L2) (alternate)| fame: 


} CatSw 
Par pot olan aaa Device type: Cisco Switch-CatOS ANY 

Seer Ne? Outbound Interface: scO 
IP Address: 10.1,1.11 
Mac Address: 00:60:47:f8:7a:ff Jun 22, 2004 5:31:15 PM PDT 
Zone: cA 
Managed by: pnmars (a) 
Status: Active 
Default gateway: 10.1.1.1 


Recommended Policy /Command 


set port disable 5/10 
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This screen contains information about the device, along with recommended policies or commands for 
mitigating the compromised host (in the example, 10.1.252.250). 


Step2 — If the device where the mitigation command to be downloaded is a Layer 2 device (such as in the example 
Mitigation Confirmation Dialog), a red Push button appears that you can click to mitigate the 
compromised host. If you select the push button, the Mitigation Confirmation Dialog appears. 


wy 


Note If the device where the mitigation command to be downloaded is a Layer 3 device, the Push button 
shown in red on the Mitigation Information screen is greyed out and you must use the suggested 
commands directly on the device to mitigate the compromised host. 
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Figure 19-24 Mitigation Confirmation screen 


ay INCIDENTS | Login: Administrator, Administrator (pnadmin) :: Jun 14, 2004 3:50:57 PM PDT :: 


Download Mitigation Command 


Device Name: CatSw 
Port/Interface Name: 5/9 
Access Type: SNMP 


SNMP RW Community String: 


Policy /Command: set port disable 5/9 


Are you sure you want to download the mitigation command to this device? 


Yes 
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wy 


Note The SNMP RW community string must be enabled for the MARS to download a mitigation command to 
a device using the Access Type SNMP. 


Step3 Click Yes to confirm the mitigation of the device. 
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This chapter discusses the following topics: 
¢ Queries 
e Viewing Events in Real-time 
e Perform a Long-Duration Query Using a Report 
e Perform a Batch Query 


e Reports 


Queries 


On the Query page, you can run reports as on-demand queries, or create your own query. Many links 
from other pages bring you to the query page, which then partially populate the query’s criteria. Once 
you have submitted a query, you can save it as a report or a rule. 


Figure 20-1 The Local Controller Query Table 


@ 


Query type: Event Types ranked by Sessions, 0h:10m |Edit| | Clear 


Source IP Destination IP Service Events Device Reported User Keyword Operation Rule |Action 


N N a = ‘i 
® ® @} 
1 |Click to set the query type and time range 2  |Click Clear to return query values to default 
criteria. values. 
3 Quick query fields permit entry of values 4 Click on a field value to open the dialog box 
without opening dialog box for the field. for that field. 
5 Save the query as a report or as a rule. 6 (Click Submit Inline to run the query. 
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To Run a Quick Query 
Step1 Enter a source IP, destination IP, or a service into the quick query field. 
Step2 Click the Submit Inline button to run the query. 


Figure 20-2 Running a Quick Query 


fo _}2 Ve Ve _JL_i 
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To Run a Free-form Query 


Step 1 


Step 2 


Step 3 


Step 4 
Step 5 


Enter a source IP, destination IP, or a service into the quick query field. 


Figure 20-3 Running a free-form query 


Specify raw message keywords: 


ee 
Close 
ae Hf [or v 
ad eel | 
ae CoCdSCsC 
a AC 
Aw At None ¥ 
ee Co) 8B [one 
4 w [ } 4 None v 
ee Cod [oe 
Ss BB None v 
a 
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Click the name of the query ([None] appears as the name if you have none saved) or Edit to enter the 
rest of the query. You can also click the parentheses icon ( 4] )to add parentheses for nested queries or 


click the trash can icon ( ff) to remove parentheses. 


Under Search String enter strings to query; under Operation, select the operation (AND, OR, NOT). For 


the final item in the list, select None. 
Click the Apply button. 
Click the Submit button to run the query. 
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Note 


The free-form query cannot be saved as a rule. 


To Run a Batch Query 


Step 1 


Step 2 


Enter your data for either a simple or free-form query. If your query is expected to take a long time to 
run, instead of Submit Inline, you may given the option of having it run as a batch query. 


Figure 20-4 


Query type: Event Types ranked by Sessions, 0h:i0m 


Edit] [Clea 


a 


Construct a Query to Run in Background (Batch Query) 


Source IP 


Destination IP 


Service 


Events 


Device 


Reported User 


Keyword [Operation 


Rule |Action 


ANY 


ANY 


ANY 


Click Submit... to make your selection. 


Figure 20-5 


Choose Query Submission Method 


ANY = 


This query will likely take a significant amount of time to complete. 


ANY 
Apply 


ANY 


Choosing the Query Submission Method 


ANY 


ANY 


None 


ANY ANY 


Save As Report 


Save As Rule 


Submit Inline 


To have the query run in the background, select "Submit Batch." The results will be sent to you via email (assuming 4 correct entry in your user 
profile), and will be saved for viewing later. If you desire, the query can be run again at a future time and the previously computed results will be 


reused, 


To run the query immediately, select "Submit Inline." The results will be displayed in your browser as soon as the query completes; no results will 
be saved and no email will be sent. 


141316 


Submit Inline Submit Batch 


wo 
ise] 
st 
ise) 
st 
pad 


To submit as a standard inline query, click Submit Inline.To submit your query as a batch query, click 
Submit Batch. Your query is submitted, and you are automatically taken to the Batch Query tab. 


If your query is very large, you may only be give the options of Save as Rule, Save as Report, or Submit 


Batch. 


Figure 20-6 


Query Event Data 


Click the cells below to change query criteria: 


Query type: Event Types ranked by Sessions, 2dd:0hh:0mm:0ss 


Change Query Criteria 


Source IP 


Destination IP 


£{10.1.1.6] 10.1.1.6 


my group {10.0,0.0 
255.0,0.0] n-10,0,0.0/8 


BackOritice (src port: 


ANY, dst port: 32337, 
proto: TCP), BackOrifice 
(sre port: ANY, dst port: 
32338, proto: TCP) 


DIO) EJ 


vj 


Keywords: [ None ] 


ANY ANY 


None 


ANY ANY 


ANY 


Save As Report Save As Rule Submit Batch 
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To submit your query as a batch query, click Submit Batch. Your query is submitted, and you are 
automatically taken to the Batch Query tab. 


Figure 20-7 Select Batch Query 
Page Refresh Rate 
| Never v 


Batch Query Selection 


Owner [Query [Status [Submitted Time Range 
¢ Administrator, Administrator 00 
(pnadmin)} 


Event Types ranked by Not Never 
Run 


2dd:Ohh:10mm:0ss 


View HTML | ¥iew Results Resubmit Stop Delete 
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1 to 1 of 1/25 per page v 
Step3 To watch the status of the query in real-time, you can use the drop-down list to change the Page Refresh 


Rate from Never (the default) to 1 minute, 3 minutes, 5 minutes, 10 minutes, 15 minutes, or 30 minutes. 


Step4 ‘To view the results of the batch query as it is running, click View Results. This can be done while the 
query is in progress. 
If the email address in your user profile on the MARS is valid, the results of your batch query are emailed 


to you when the query has completed, and can also be viewed by clicking QUERY / REPORTS > Batch 
Query > View Results. 


wy 


Note When youclick View Results while the query is in progress, the results compiled up to that moment are 
recomputed. This can make the display take longer to appear than after the results are compiled. 


To Stop a Batch Query 


Step 1 Click QUERY/REPORTS, then click the Batch Query tab. 
Step2 Click Stop. The Status of the query changes to Finished. 


To Resubmit a Batch Query 


You can resubmit a batch query if you want to restart it. A resubmitted batch query will use previously 
computed results, thus resulting in a faster query than one submitted for the first time. 


Step 1 Click QUERY/REPORTS, then click the Batch Query tab. 
Step2 Click Resubmit. The Status of the query changes to In Progress. 
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To Delete a Batch Query 


Step 1 Click QUERY/REPORTS, then click the Batch Query tab. 
Step2 Click Delete. 
Step3 =‘ In the confirmation window, click Delete to confirm. 


\ 


Note You can only see your own batch queries and their results. The batch queries of others and their results 
are not viewable by you, and your batch queries and their results are not viewable by others. 


Selecting the Query Type 


Figure 20-8 Clicking the Query Type or Edit link 


Query type: Event Types ranked by Sessions, thh:Omm:0ss 


You can select different query criteria by clicking the Query Type link or Edit button. This lets you 
determine a query’s result format, rank, time, whether it only uses firing events, and the number of rows 
returned. 


143444 


Figure 20-9 The Query Criteria: Result Page 


Result Format: [Event Type Ranking 


Order/Rank By: 


Session Count 


Filter by Time: 


c Last: [0 |Days[o JHrs[10 |Mins 


c Start: [2005 | February bd fi =] [ts Jxrs[oo__|mins 
End: [200s =] [February =1[29 e][ts_Jrrs[oo_|mins 


© Real Time 


Use Only Firing Events: [— 


Maximum rank returned: 
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Result Format 


e Event Type Ranking 


Returns the most reported event types. Ranked by either: number of sessions containing at least one of 
the event type or by bytes transmitted in sessions that contain events that meet the query criteria. 
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e Event Type Group Ranking 


Returns either pre-defined or user defined grouped event types. Ranked by either: number of sessions 
containing at least one event type contained in the group or by bytes transmitted in sessions that contain 
events that meet the query criteria. 


e Source IP Address Ranking 


Returns source IP addresses. Ranked by number of sessions with that source IP address or by bytes 
transmitted in sessions that contain events that meet the query criteria. 


¢ Network Ranking 


Returns top networks that exists in MARS. Ranked by either: number of sessions that contain events that 
meet the query criteria or by bytes transmitted in sessions that contain events that meet the query criteria. 
If a network is excluded, it is excluded from all results. 


e Network Group Ranking 


Returns top network groups that exists in MARS. Ranked by either: number of sessions that contain 
events that meet the query criteria or by bytes transmitted in sessions that contain events that meet the 
query criteria. If a network is excluded, it is excluded from all results. 


e¢ Source Network Ranking 


Returns top source networks that exists in MARS. Ranked by either: number of sessions that contain 
events that meet the query criteria or by bytes transmitted in sessions that contain events that meet the 
query criteria. If a network is excluded, it is excluded from all results. 


e Source Network Group Ranking 


Returns top source network groups that exists in MARS. Ranked by either: number of sessions that 
contain events that meet the query criteria or by bytes transmitted in sessions that contain events that 
meet the query criteria. If a network is excluded, it is excluded from all results. 


¢ Destination Network Ranking 


Returns top destination networks that exists in MARS. Ranked by either: number of sessions that contain 
events that meet the query criteria or by bytes transmitted in sessions that contain events that meet the 
query criteria. If a network is excluded, it is excluded from all results. 


e Destination Network Group Ranking 


Returns top destination network groups that exists in MARS. Ranked by either: number of sessions that 
contain events that meet the query criteria or by bytes transmitted in sessions that contain events that 
meet the query criteria. If a network is excluded, it is excluded from all results. 


e Destination IP Address Ranking 


Returns destination IP addresses. Ranked by either: number of sessions with that destination IP address 
or by bytes transmitted in sessions that contain events that meet the query criteria. 


e Source Port Ranking 


Returns source ports. Ranked by either: number of sessions with that source port or by bytes transmitted 
in sessions that contain events that meet the query criteria. 


e Destination Port Ranking 


Returns destination ports. Ranked by either: number of sessions with that destination port or by bytes 
transmitted in sessions that contain events that meet the query criteria. 


e Protocol Ranking 


Returns most used protocols. Ranked by either: number of sessions with that protocol or by bytes 
transmitted in sessions that contain events that meet the query criteria. 
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¢ Reporting Device Ranking 


Returns most active reporting devices. Ranked by either: number of sessions that contain events from 
the device or by bytes transmitted in sessions that contain events that meet the query criteria. 


e Reporting Device Type Ranking 


Returns most active reporting device types. Ranked by either: number of sessions that contain events 
from a device of that type or by bytes transmitted in sessions that contain events that meet the query 
criteria. 


¢ Reported User Ranking 


Returns information about users from reporting devices such as: Windows clients, Solaris clients, etc. 
Ranked by either: number of sessions that contain events from a reported user or by bytes transmitted in 
sessions that contain events that meet the query criteria. 


¢ Matched Rule Ranking 
Returns top firing rules. Ranked by number of incidents. 
¢ Matched Incident Ranking 


Returns incidents. Ranked by either: number of sessions that contain events that meet the criteria that 
contributed to the incident or by bytes transmitted real time in sessions that contain events that meet the 
query criteria. 


e All Matching Sessions 


Returns all sessions that contain events that meet the criteria. Sessions that contain a common set of 
event types are grouped together. They are also sub-grouped by session source IP address and session 
destination IP address. Sessions in the same sub-group are ordered by time. Real Time results are 
available for this Result Type. 


e All Matching Events 


Returns events. Ranked by time with the most current first. Real Time results are available for this Result 
Type. 
e All Matching Event Raw Messages 


Returns the raw messages associated with events. Ranked by time with the most current first. Real Time 
results are available for this Result Type. 


e¢ NAT Connection Report 

Returns NAT connections. Ranked by time with the most current first. 
e MAC Address Report 

Returns MAC addresses. Ranked by time with the most current first. 
¢ Unknown Event Report 


Returns events that are not fully processed by the MARS. In some cases, event information such as the 
five tuple (source IP, source port, destination IP, destination port, and protocol) might not be present, 
hence can not be queried in real time. 


This selection determines the ranking or order of the query’s results. These selections are determined by 
the kind of Result Format that you use when you run the query. 


e Session Count 


The number of sessions that contain events that meet the criteria that contributed to the incident. 
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e Bytes Transmitted 

The number of bytes transmitted in sessions that contain events that meet the query criteria. 
e Time 

Most current results appear first. 
e Incident Count 


Largest number of incidents appear first. 


Filter By Time 


e Last 

The present time minus the number of days, hours, and minutes entered. 
e = Start/End 

Absolute literal time ranges defined by the date to the minute. 
e Real Time 


Streams rolling real-time results from recent past to current time. Result Formats that work in real time 
are: *All Matching Sessions, page 20-7, *All Matching Events, page 20-7, and *All Matching Event 
Raw Messages, page 20-7. 


Real Time results appear in a normal browser window. Moving the scroll bar stops the “rolling” behavior. 
Clicking the Resume button on the bottom of the page allows the scrolling to resume. 
Figure 20-10 Click the Resume Button to Start the Page Rolling 


11.254 [a] 18088 [g] UDP [9] ProtegoHQ eget [a] 
= 
om) 


1 to 7 of 1000 (1000 new) [35 per page 
oO 
g 
1 |Top row visible 2 |Bottom row visible 
3 |Total rows queried since start 4 |Number of new queries pulled when this page 
last refreshed 


Use Only Firing Events 


Select this if you want only events that fired incidents to return information. 


Maximum Number of Rows Returned 


Select the number of rows that you want displayed. 
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Queries 


Selecting Query Criteria 


To Select a Criterion 


Step 1 


Step 2 


Step 3 


Select the criteria that you want to edit by clicking it. 


Figure 20-11 


Destination IP 

ot 
Move the items that you want to query from the right to the left of the filter by selecting the check box 
next to them, and clicking the Equal and Not Equal buttons. 


Clicking any to narrow your criteria 


Figure 20-12 Selecting Variables 


Select All 


Toggle Equal 


oO ANY * 
- STARGETOL 
yw $TARGETO2 
o $TARGETO3 
Remove D> _ liam $TARGETO4 
A r $TARGETOS 
p $TARGETOS 
r STARGETO7 
oO $TARGETOS 
oO 
7 4 Ba 
a 


> 
a 
a 


Edit Delete 


Grouped As 


143442 


60 ® @® 


You can select a variety of different variables, events, devices, addresses from the filter page. The 
following number correspond with the numbers in the preceding graphic: 


1. Check the boxes next to the items in the Sources Selected field to select them, and click the Toggle 
Equal button to change them between equal and not equal. 


2. Click the Select All button to select all items in the Sources Selected field. (Note: if you have items 
highlighted in the Sources Selected field, clicking Select All will de-select them.) 


3. Use the Equal and Not Equal buttons to bring highlighted items from the Sources Available field 
into the Sources Selected field. 


4. Filter sources from this drop-down list. 
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Query Criteria 


Source IP 


Step 4 


5. Enter search text, and click Search to move items that match the search criteria from the Sources 
Available field to the Sources Selected field. 


6. To add a new item to the sources, click the Add button. To edit or delete an existing source, click 
the Edit or Delete button. See IP Management, page 23-3 for more information. 


7. Click an item or items in the Sources Selected field, and use the Remove button. 


8. To move IP values up into the Sources Selected field, click the Equal | # == | (Up) icon, or the Not 
Equal | &'= | (Up) icon. 

9. Check the radio button next to IP or Range, and enter an IP address or a range of IP addresses into 
their respective fields. 


10. Select items in the Sources Selected field by clicking them. Enter a group name, and click the 
Grouped As button to group them. 


11. Once you have chosen the query criteria that interests you, click Apply to return to the Query page. 
Repeat this selection process for other query data. 


Click the Submit button to run the query. 


The following list describes the selections in the Query Event Data table. 


e Pre NAT source addresses 
Specifies that the constraints entered are the session endpoints. 
e Post NAT source addresses 
Specifies that the constraints entered are the source as appearing at the destination. 
e ANY 
No constraint is placed on the source IP addresses. 
e Variables 
Signify any one IP address, only useful for queries in tandem with the same variable. 
e IP addresses 
IP addresses present on devices in the system or user entered dotted quads. 
e IP ranges 
The range of addresses between two dotted quads. 
e Networks 
Topologically valid networks. 
e Devices 


The hosts and reporting devices present in the system. 
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Event Types 


Device 


Queries 


e Post NAT destination addresses 
Specifies that the constraints entered are the session endpoints. 
e Pre NAT destination addresses 
Specifies that the constraints entered are the destination as appearing at the source. 
e ANY 
No constraint is placed on the source IP addresses. 
¢ Variables 
Any one IP address, only useful for queries in tandem with the same variable. 
e IP addresses 
IP addresses present on devices in the system or user entered dotted quads. 
e IP ranges 
The range of addresses between two dotted quads. 
¢ Networks 
Topologically valid networks. 
e Devices 


The hosts and reporting devices present in the system. 


e ANY 

No constraint is placed on the source or destination ports or protocol. 
e Service variables 

Any one set of destination port and protocol, only useful for queries in tandem with the same variable. 
e Defined services 


Services on the database. 


e ANY 

No constraint on the event type. 
e Event types 

Events that have been merged into types. 
e Event type groups 


Groups of event types. 


e Devices 
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Severity/Zone 


Operation 


Rule 


Action 


The reporting devices present in the system. This restricts the query to a subset of the devices that report 
to the MARS. 


e ANY 
No constraint on the event type severity. 
¢ Green 
Low-severity events 
e Yellow 
Medium-severity events 
e Red 
High-severity events 
e Zone 


Events reported by devices in the indicated zone. 


e None 

Defines a single-line query. 
e AND 

Boolean “and” that defines a two or more line query. 
¢ OR 

Boolean “or” that defines a two or more line query. 
e FOLLOWED-BY 


Time conditional query (e.g.: Y must happen after X) that defines a two or more line query. 


e Empty field — Rules Chosen field 
When this field is empty, it acts like an ANY selection. No constraint is placed on the sub-set of events. 
e Rule 


Restricts the query to the sub-set of events that contributed to the incidents of the specified rules firing. 


e Empty field —- Empty Actions Chosen field 
When this field is empty, it acts like an ANY selection. No constraint is placed on the sub-set of events. 
e Actions 


Restricts the query to the sub-set of events that contributed to the incidents of rules that have the 
specified notifications as part of their actions. (See page ??? rules for more information?) 
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Saving the Query 


You can save query criteria to re-use as reports or rules. 
To save a query as a report 


This takes the query that you are using and creates a report. For more information on creating reports, 
see Reports, page 20-22. 


To save a query as a rule 


This takes the query to the rules page, populating the rules with the selected query criteria. Likely, you 
must identify additional criteria to complete the rule. For more information on creating rules, see Rules, 
page 21-1. 


Viewing Events in Real-time 


The Real-time Event viewer is a query option that permits you to view real-time events as follows: 


e View raw events as they stream to MARS before they are sessionized, with a maximum 5-second 
delay 


e View a sessionized event stream—more delay is possible when there are many events in a session 


The real-time events display as a continuously scrolling screen. You can configure query criteria to filter 
what is displayed. When viewing raw events, sessionization is not impeded, all the parsed raw events are 
sessionized per normal MARS operation. MARS 


Restrictions for Real-time Event Viewer 


Real-time event queries should be made only from a browser instance that was used to login to MARS. 
The real-time query will not have reliable results if it is executed from a browser instance spawned from 
the original login instance (for example, a new browser window launched with Ctrl+N, File>New>New 
Window, or right-click {link on MARS interface }>Open in New Window). 


Multiple real-time queries can operate in multiple browser instances at the same time, but you must login 
to MARS with each browser instance. 


Procedure for Invoking the Real-Time Event Viewer 


To invoke the real-time event viewer, complete the following steps: 


Step 1 Navigate to the Query home page as shown in Figure 20-13. 
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Figure 20-13 Query Home Page 


Cisco Systems 


SUMMARY || INCIDENTS [Query /Reronts | RULES || MANAGEMENT || ADMIN || HELP 


es QUERY / REPORTS | CS-MARS Standalone: earth2 v0.0 Login: Administrator (pnadmin) :: | Logout 


Query 


Select Case: | no 


cted., ¥ 


Load Report as On-Demand Query with Filter 


Sel 


Incident ID 


Group | 


Select Report... v 


Query Event Data 


Click the cells below to change query criteria 


Query type: Event Types ranked by Sessions, 0h:10m [Edit] | Clear 
Source IP Destination IP Service Events [Device [Reported User Keyword [Operation Rule [Action 
ANY ANY ANY ANY ANY ANY ANY None ANY ANY 
i { i { ANY Apply 
Save As Report Save As Rule Submit Inline is 
+ 
= 
Copyright 2006 Cisco Systems, Inc. Summary :: Incidents :: Query / Reports :: Rules :: Management :: Admin :: Help Feedback | 2 
All righ ed 23 
° . : : . < 
Step2 Click Edit. The Query edit dialog appears, as shown in Figure 20-14. 
Figure 20-14 Configuring Real-Time Event Viewer Query 
Query Event Data 
Click the cells below to change query criteria: 
Query type: Event Types ranked by Sessions, 0h:10m Clear 
Source IP Destination IP [Service Events Device Reported User Keyword Operation Rule Action 
ANY ANY ANY ANY ANY ANY ANY None ANY ANY 
Apply 
Result Format: 
Order/Rank By: [Time ¥ 
Filter by Time: 
© Last:|0 Days|0 Hrs[i0 |Mins 
 start:[ 2006 |) May v|i2 v2 Jrrs[z2]mins 
End: | 2006 ||| May vii v2 Jurs[22]mins 
© Real Time: | Raw events v 
Use Only Firing Events: = [~ 
Maximum rank returned: 
o 
t 
8 
Apply | — 


Step3 Do the following substeps: 


a. From the Result Format dropdown list, select All Matching Events or All Matching Event Raw 
Messages. 


b. Click the Real Time radio button, and select Raw events or Sessionized Events from the dropdown 
list. 


All Matching Events with Raw events displays Event ID, Event Type, Source IP/Port, Destination 
IP/Port, Protocol Time, and Reporting Device fields. 


All Matching Events Raw Messages with Raw events displays Event ID, Event Type, Time, 
Reporting Device, and Raw Message fields. 


Either Result Format type with Sessionized Events displays Event/Session/Incident ID, Event Type, 
Source IP/Port, Destination IP/Port, Protocol, Time, Reporting Device, Path/Mitigation, and Tune 
fields. 
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c. Click Apply. 


The Query Event Data screen appears with the Save as Report and Save as Rule buttons gray and 
inactive, as shown in Figure 20-15. 


Figure 20-15 Real-Time Event Query to Submit 


Load Report as On-Demand Query with Filter 
Sroup... ¥) 


Incident ID: Show 


n ID: Show 


| Select Report... ¥ 


Query Event Data 
Click the cells below to change query criteria 


Query type: Events ranked by Time, Real Time(raw events) [Edit] [Clear 


Source IP Destination IP Service Events |Device _|Reported User Keyword _ [Operation Rule [Action 
ANY ANY ANY ANY ANY ANY ANY None ANY ANY 
ANY ¥ Apply 
~ 
st 
Save As Report Save As Rule Submit a4 


Step4 Modify the parameters of the Query Event Data filter as you require and click Submit. 


\ 


Note The Operation, Rule, and Action parameters of the Query Event Data filter do not function for 
the real-time event viewer. 


Real-time results begin to scroll up from the bottom of the page within 5 seconds, as shown in 
Figure 20-16. Real-time raw events are shown in this example. 


Figure 20-16 Viewing Events in Real-Time 


Event ID JEvent Type [Time [Reporting Device [Raw Message 
Brsusese UNKNOWR Vevice Event Maris, 2UUb Sin/iLU Gartne IU41.1 Sat Wov 2 LbiUcile 2UuUc =104>foPIA-b-SUZUUL: Bult nbounG TCP 
Type PM PST connection 10056383 for faddr 219,51,92,21/64776 gaddr 67,118,229.242/80 laddr 
10.1.1.30/80 
87589899 Unknown Device Event Mar 15, 2006 5:57:10 earth2 10.4.1.1 Sat Nov 2 16:02:12 200 302001: Built inbound T 
Type PM PST connection 775 9 for faddr 24 27 gaddr 67,118.2 
laddr 10.1.1.3 
87589900 Unknown Device Event Mar 15, 2006 5:57:10 earth2 10.4.1.1 Sat Nov 2 16:02:12 2002 <134>%PIX-6-302001: Built inbound TCP 
Type PM PST connection 15424022 for faddr 46,144.232,118/31134 gaddr 67,.118.229.242/80 
laddr 10,1,1,30/80 
87589901 Unknown Device Event Mar 1 65:57:10 earth2 10.4.1.1 Sat Nov 2 16:02:12 2 <13: O01: Built inbound TCP 
Type PM PS connection 14518954 f. dr 27.64.2 ddr 67,.118.229.242/80 laddr 
10.1.1,30/80 
87589902 Unknown Device Event Mar 15, 2006 5:57:10 earth2 10.4.1,1 Sat Nov 2 16:02:12 2002 <134>%PIX-6-302001: Built inbound TCP 
Type PM PST connection 15166103 for faddr 195.167.19.52/31447 gaddr 67.118.229.242/80 
laddr 10,1.1.30/80 
87589903 Unknown Device Event Mar 15, 2006 5:57:10 earth2 10.4.1,1 Sat 2 16:02:12 2002 %-6-302001: Built inbound TCP 
Type PM PST connection 4438904 for faddr 95.55.162.89/34335 gaddr 67,118.229.242/80 laddr 
10.1.1.30/80 
87589904 Unknown Device Event Mar 15, 2006 5:57:10 earth2 10.4,1,1 Sat Nov 2 16:02:12 2002 <134>%PIX-6-302001; Built inbound TCP 
Type PM PST connection 3063834 for faddr 108.48.250,124/13434 gaddr 67.118.229.242/80 
laddr 10,1.1.30/80 
87589905 Unknown Device Event Mar 15, 2006 5:57:10 earth2 10.4,1.1 Sat Nov 2 6-302001: Built inbou 
Type PM PST connection 15782 23 gaddr 67.118.2 
laddr 10,1.1.30/80 
87589906 Unknown Device Event Mar 15, 2006 5:57:10 earth2 10.4.1,1 Sat Nov 2 16:02:12 2002 <134>%PIX-6-302001; Built inbound TCP 
Type PM PST connection 15580904 for faddr 58.74.186.118/9997 gaddr 67,118.229,.242/80 laddr 
10.1.1.30/80 
87589907 Unknown Device Event Mar 15, 2006 5:57:10 earth2 10.4.1.1 Sat Nov 2 16:02:12 2002 <134>%PIX-6-302001: Built inbound TCP 
Type PM PST connection 7688160 for faddr 44,.209.154,112/31382 gaddr 67.118.229.242/80 
laddr 10.1.1.30/80 
87589908 Unknown Device Event Mar 15, 2006 5:57:10 earth2 10.4.1.1 Sat Nov 2 16:02:12 2002 <134>%PIX-6-302001: Built inbound TCP 
Type PM PST connection 744799 for faddr 201,.87.206,.66/24688 gaddr 67,.118,.229.242/80 laddr 
10.1.1.30/80 
87589909 Unknown Device Event Mar 15, 2006 5:57:10 earth2 10.4.1.1 Sat Nov 2 16:02:12 200 6-302001: Built inbound TCP 
Type PM PST connection 2107207 for faddr 208.8, 7 gaddr 67,11 242/80 laddr 
10.1.1.30/8: 


Pause 


Scroll speed: 


The Real-time event viewer display is governed by the following controls: 
e Scroll Speed—Select one of four scrolling rates. 


e Pause button —Suspends the scrolling display, there is no timeout for pause. 
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e Restart button—Restarts the display from the current time. This button appears when you pause the 
scrolling display. 


e Resume button—Restarts the display from the time when paused. This button appears when you 
pause the scrolling display. 


e Clear—Terminates the real-time query. 


Step5 = Click the active links within a real-time event record to view the related pop-up windows. For example, 
the Reporting Device Information pop-up window is shown in Figure 20-17. 


Figure 20-17 Reporting Device Information Pop-up Window 


| https://172.16.16.1 - [earth2] Device Information - Microsoft Internet Explorer provided by Cisco Systems, Inc. Cje®) 
Cisco SYSTEMS s 


Mar 15, 2006 5:56:21 PM PST 


Standalone: earth2 v0.0 Login: Administrator (pnadmin) :: 


Select Case: [to Case Selected... v View Cases 


information is nilate pology discovery, (b) host fingerprinting during incident false positive analysis and (c) reports imported from 
Vulnerability 4 ent too s-MARS, 


Static Info Dynamic Info 


Domain Name: earth2[q] 
Default gateway: 10.1.1.1 


Reporting Device Information 


Type Manager|Children Log Collects From 
To 


PN- N/A Cisco ACS 3.x on ACS, Cisco ASA 7.0 on test, Cisco ASA N/A Cisco ACS 3.x on ACS, Cisco ASA 7.0 on test, Cisco ASA 
MARS 7.0 on test2 7.0 on test2 


é| 


190149 


Should errors occur during the display of events, a message box appears, as shown in Figure 20-18. 


Figure 20-18 Real-time Event Viewer Error Message 
Microsoft Internet Explorer 


rN Real time viewer is temporarily unavailable, Please resubmit. 


190150 


Click OK to clear the message box, and restart the Real-time event viewer by clicking Submit. 


Tip To view the most recent real-time events, you can click Submit at any time, or Pause and Restart to 
reinitialize the Real-Time Event Viewer. The most recent events are always at the bottom of the output 
queue, and their freshness when you view them is limited by the number of events in the queue and the 
scroll speed of the display. 
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This ends the Procedure for Invoking the Real-Time Event Viewer. 


Perform a Long-Duration Query Using a Report 


This section explains how to create and view a long-duration query on the MARS. There are two ways 
to perform a long-duration query on the MARS: 


1. Modifying an existing report. 
Advantages: 

e The report is compiled relatively quickly. 

e You can compile data gathered over a longer time period 
Disadvantage. 


This type of query can only be used without any changes to query criteria other than time range, and can 
only be used with the following reports: 


e Activity: All - Top Destination Ports 
e Activity: All - Top Destinations 
e Activity: All - Top Event Types 
e Activity: All - Top Reporting Devices 
e Activity: All - Top Sources 
e Activity: Attacks Seen - Top Reporting Devices 
e Activity: Denies - Top Destination Ports 
e Activity: P2P Filesharing/Chat - Top Event Types 
e Activity: Scans - Top Destination Ports 
e Activity: Scans - Top Destinations 
e Activity: Unknown Events - All Events 
e Activity: Web Usage - Top Destinations by Sessions 
e Activity: Web Usage - Top Sources 
e Attacks: All - Top Rules Fired 
e Attacks: All - Top Sources 
2. Performing a batch query. 
Advantages: 
e You can modify any of the query criteria. 
e Best suited for data that spans a short time period. 
Disadvantages 
e This type of query can be slow and may take a substantial amount of time to complete. 
¢ Only Admin users can perform a batch query. 


If you want to observe activity on your MARS over a long period, you can change the duration of time 
over an existing report that runs on a regular basis, such as hourly or daily, whether they are shipped with 
the MARS or created by you. 
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Note 


Step 1 


Step 2 


Step 3 


Trying to run a long-duration query using a report that only runs “on demand” has the same effect as 
running a query; it can take just as long because it has to compile data, whereas data from the 
regularly-run reports has been precompiled on an ongoing basis. 


To query using a report, follow these steps: 


In the QUERY / REPORTS tab, click the Reports tab to obtain the Main Report window. 


Figure 20-19 Main Report Window 


Report Selection 


Name Schedule |Format|Recipients |Query Description Status Submitted |Time 
Range 
C Activity: All- Runon Normal None Query Type: NAT This report lists Network Finished: Jun 15, 2004 May 1, 2004 
NAT demand connections ranked by Time Address Translations Jun 16, 8:32:09 PM 8:21:50 PM 
Connections only Time: May 1, 2004 8:21:50 performed on non- 2004 PDT PDT - Jun 6, 
PM PDT - Jun 6, 2004 denied sessions as 4:40:36 2004 
8:31:50 PM PDT reported to MARS. 4M PDT 8:31:50 PM 
PDT 
c Activity: All- | Runon Trend None Query Type: Destination This report ranks the Finished; Jun 10, 2004 Jun 10, 2004 
Top demand Ports ranked by Sessions UDP and TCP destination Jun 10, 4:16:58 PM 3:1 PM 
Destination only Time: Thh:Omm:0ss ports of all events seen 2004 PDT PDT - Jun 
Ports by MARS overthe past 4:17:02 PM 


hour. This report is used PDT 
by pages in the 
Summary tab. 


@ Activity; All- Every hour Normal None Query Type: Destination IPs This report ranks the Finished: Jun17, 2004 Noy 30, 
Top ranked by Sessions session destinations of Jun 17, 2:15:52 PM 2003 
Destinations Time: all events seen by MARS 2004 PDT 1:05:52 PM 
28wwiddd;Ohh:10mm:0Oss over the past hour. This 2:15:52 PM PST - Jun ao 
reportis used by pages PDT 17, 2004 faa) 
in the Summary tab. 2:15:52 PM 
PDT =. 


Navigate to and then click the radio button next to the regularly-scheduled report you want to modify (in 
this example, we use Activity: All - Top Destinations). Click the Query column to edit the report. The 
Build Report window appears. 


Figure 20-20 Build Report window 


Build Report 
Click the cells below to define the report: 
% 
Name Schedule |Format|Recipients Query Description |Status Submitted |Time Range 
Activity; All- Every Normal None Query Type: Destination IPs This report ranks the Finished: Jun 16, 2004 Noy 29, 2003 
Top hour ranked by Sessions session destinations of all Jun 16, 7:15:42 PM 6:05:42 PM 
Destinations Time: events seen by MARS over 2004 PDT PST - Jun 16, 
28wwiddd:Ohh:10mm:0ss the past hour. This report 7:15:42 PM 2004 7:15:42 
is used by pages in the PDT PM PDT 
Summary tab, 
Submit | Previous | | Next 
Time Range: 
@ Last:[200 |Days[o Hrs]10__|Mins 
© Start:| 2004 ||| June vi[ie vi[t9_]Hrs[4z__]mins 
End: | 2004 |¥|| June vii1e vij19  |Hrs[52__|Mins 
wo 
ao 
wo 
Submit | Previous Next |3 


In the lower portion of the Build Report window, change the Time Range the report (Activity: All - Top 
Destinations) covers to the duration you want it to cover. 


User Guide for Cisco Security MARS Local Controller 
P2018 78-17020-01 | 


| Chapter 20 Queries and Reports 


View a Query Result inthe ReportTab I 


Step4 = Click the Submit button to run the report and return to the Main Report window. 


View a Query Result in the Report Tab 


To view a query in the Report tab, follow these steps: 


Figure 20-21 Main Report window (bottom) 


t Activity: All- Every hour Normal None Query Type: Destination IPs This report ranks the Finished: Juni? 
Top ranked by Sessions session destinations of Jun 17, 2:15:5 
Destinations Time: all events seen by MARS 2004 PDT 


28wwid4dd:Ohh:10mm:0ss over the past hour. This 2:15:52 PM 
reportis used by pages PDT 
in the Summary tab, 


c Activity: All Run on Trend None Query Type: Destination This report ranks the Finished: 
Events and demand Ports ranked by Sessions UDP and TCP destination Jun 
Netflow - Top = only Time: Lhh:Omm:Oss ports of all events 200 
Destination (including Netflow 
Ports events) seen by MARS PDT 


over the past hour. This 
report is used by pages 
in the Summary tab, 


c Activity: All Run on Normal None Event type: Info/AllSession, This report ranks all Not Run 
Sessions - Top demand Query Type: Destination destination ports by 
Destination only Ports ranked by Bytes bytes transferred. 
Ports by Bytes Transmitted 


Time: Ohh:10mm:0ss 


c Activity: All Run on Normal None Event type: Info/AllSession, This report ranks all Not Run 
Sessions - Top demand Query Type: Destination IPs destinations by bytes 
Destinations by only ranked by Bytes Transmitted transferred. 

Bytes Time: Ohh:10mm:0ss 


¥Yiew Report Resubmit add Edit Delete 


143799 


Step1 At the bottom of the Main Report window, click the radio button next to the report (Activity: All - Top 
Destinations). 


Step2 From the drop-down list on the bottom of the Reports page, select either: 
e View HTML: to view the report as an HTML file. 
e View CSV: to view the report as a CSV (comma-separated values) file. 


Step3 = Click the View Report button. 


Note The Status column of the report lets you know whether the report has finished before viewing. You can 
view a partially-completed report, but it might not contain all the data you want to examine. You can also 
refresh the screen to update the Status column. 


Perform a Batch Query 


This type of long-duration query can take a long time to perform and is more suitable for a shorter 
duration of time. 
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Note Only Admin users can perform a batch query. 


To perform a batch query, follow these steps: 


Step 1 Click the QUERY / REPORTS > Query tab. The Query window appears. 


Figure 20-22 Query window 


Query Event Data 
Click the cells below to change query criteria: 


Query type: Event Types ranked by Sessions, Ohh:10mm:0ss 


Destination IP Events|Device|Severity|Zone|Operation|Rule|Action|Reported 


ANY ANY ANY ANY ANY ANY ANY None ANY ANY ANY 


Keywords: [ None ] [Edit] 


143796 


Save As Report Save As Rule Submit Inline 


Step2 —_In the Query window, click the Edit button to change the query criteria. The Query Event Data window 
appears. 
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Figure 20-23 Query Event Data window 


Query Event Data 
Click the cells below to change query criteria: 


Query type: Sessions ranked by Time, Ohh:i10mm:Oss | Edit 


[Source My [Destination if |Service [Events |Device |Severity |Zone [Operation [Rule [Action [Reported User 
H-10,1,252,250 H-65,54,153, 118 ANY ANY ANY ANY ANY None ANY ANY ANY 


Keywords: [ None ]| Edit 


Apply 


Result Format: | All Matching Sessions Mi 


Order/Rank By: | Time ¥ 


Filter by Time: 


@ Last:|o Days|0 Hrs|10 |Mins 


C start:| 2004 |¥'| june ¥)| 22 wife Mins 
End: | 2004 ¥ || June » || 22 ¥|[18 |Hrs|48__|Mins 
© Real Time 


Use Only Firing Events: [~ 


Maximum rank returned: 


143795 


Apply 


Step3 = In the Query Event Data window, you can change the query criteria. (For more information on query 
criteria, see Query Criteria, page 20-10). By clicking on various parameters you can change the nature 
of the query. In this case we are specifying a Source IP address of 10.1.1.6, a Destination IP address 
range previously saved as mygroup, and setting the duration of the query to the past 2 days.Click either 
Apply button to apply your changes to the query. The Query Save/Submit window appears. 


Figure 20-24 Query Save/Submit window 


Query Event Data 
Click the cells below to change query criteria: 


Query type: Event Types ranked by Sessions, 2dd:0hh:0mm:0ss 


Source IP Destination IP Service Events |Device|Severity|Z2one|Operation Sean Reported 
User 
£20.2,.2.6}7 10,2.1.6 my group £10.0.0.0 f BackOritfice (sre port: ANY ANY ANY ANY None ANY ANY ANY 


255.0.0,0} n-10,0.0.0/8 ANY, dst port: 31337, 
proto; TCP), BackOrifice 
(src port: ANY, dst port: 
31338, proto: TCP) 


Oooo er 


Keywords: [ None ] [Edit] 


143794 


Save As Report Save As Rule Submit Batch 
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Step4 The Query Save/Submit window asks you to choose from the options of Save as Rule, Save as Report, 
or Submit Batch. To submit your query as a batch query, click Submit Batch. Your query is submitted, 
and you are automatically taken to the Batch Query tab. 


Figure 20-25 Batch Query tab 
Page Refresh Rate 
1 minute ¥) 


Batch Query Selection 


Owner Query [Status [Submitted Time Range 
tf Administrator, Query Type: Event Types ranked by Finished: Jun 21, 2004 Jun 21, 2004 Jun 21, 2004 7:57:02 PM PDT - 
Administrator (pnadmin) Sessions 8:07:08 PM PDT 6:07:02 PM PDT Jun 21, 2004 6:07:02 PM PDT 
Time: Ohh:10mm:Oss 
C@ Administ Query Type: Event Types ranked by Not Run Never May 


Administ (pnadmin) PM PDT 


dd:Ohh:10mmi:Oss 


c Administrator, ype: Event Types ranked by Finished: Jun 13, 


2 PM PDT 


Administrator (pnadmin} 2004 2:17:43 PM PDT 12 :32 PM PDT 
d:0hh:Omm 

@ Administrator, e: != Built/teardown/permitted IP Stopped: 16% May 14, 2004 12: 5 PM PDT 

- Jun 13, 2004 12: PM PDT 


Event Types ranked by 


dd:Ohh:10mmi:Oss 
vent Types ranked by Finished: Jun 13, Juni 0 May 3 00 Zs 5 PM PDT 
2004 1:37:15 PM PDT 12 | S PM PDT 


v:6dd:Ohh:10mm:0ss 


‘. View Results Resubmit Stop Delete 


L 


143785 


Step5 To watch the status of the query in real-time, you can use the Batch Query tab drop-down list to change 
the Page Refresh Rate from Never (the default) to 1 minute, 3 minutes, 5 minutes, 10 minutes, 15 
minutes, or 30 minutes. 


Step6 To view the results of the batch query as it is running, click the radio button next to your query (here it’s 
highlighted in green) and click View Results. This can be done while the query is in progress. 


If the email address in your user profile on the MARS is valid, the results of your batch query are emailed 
to you when the query has completed. You can also view the results of your batch query by clicking 
QUERY / REPORTS > Batch Query > View Results. 


Note When youclick View Results while the query is in progress, the results compiled up to that moment are 
recomputed. This can make the display take longer to appear than after the results are compiled. 


Using the Reports page, you can build repeatable queries, edit and delete current reports, run reports, 
and view reports in either HTML or CSV (comma separated value) formats. 


Predefined System Reports are treated as global reports. Global Controller receives report data once its 
connected to the Local Controller. Previous report results (prior to managing the Local Controller) will 
not be pushed up to Global Controller. Thus viewing of reports will not include the information before 
the Local Controller becomes active. 


When you view a report, you are viewing the last instance that ran. If you want to view an 
up-to-the-minute report, resubmit the report before viewing it. 
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Reports Wi 
Report results are purged from the database after a purge interval, as tabulated in Table 20-1. 
Table 20-1 Maximum Database Retention Limits for Report Results 
Cisco Security MARS Model Maximum Number of Stored Reports’ Database Purge Interval” 
CS-MARS-20-K9 1,000 ranking reports 3 months 
5,000 event/session reports 
CS-MARS-50-K9 1,000 ranking reports 3 months 
5,000 event/session reports 
CS-MARS-100-K9 1,000 ranking reports 6 months 
5,000 event/session reports 
CS-MARS-100E-K9 1,000 ranking reports 6 months 
5,000 event/session reports 
CS-MARS-200-K9 1,000 ranking reports 6 months 
5,000 event/session reports 
CS-MARS-GC-K9 1,000 ranking reports 12 months 
5,000 event/session reports 
CS-MARS-GCM-K9 1,000 ranking reports 12 months 
5,000 event/session reports 
1. Table values are for Cisco Security MARS Release 4.1.5. In Release 4.1.4 and prior, the maximum number of ranking reports 


is 100, maximum number of event/session reports is 1,000. 


2. As of Cisco Security MARS Release 4.1.5. In Release 4.1.3, and 4.1.4, report results are retained for one year in the MARS 
database before they are automatically purged. In Releases prior to Release 4.1.3, report results are retained indefinately. The 
purge interval cannot be changed. 


Report Type Views: Total vs. Peak vs. Recent 


Where alerts provide up-to-the-minute views of high-priority incidents, reports aggregate sessions into 
different views. Reports correlate based on the three data points: 


e Period of time 
¢ Query criteria 
e View type 


The period of time defines boundaries around the analyzed session data based on when it was recorded. 
Query criteria restrict the set of sessions that will be aggregated to that which matches your criteria. 
Criteria can include source address, destination address, network service, event, reported user, and 
reporting device. The view type defines how to aggregate the matched data into a meaningful report 
view—one that matches the type of study in which you are interested. 


Note 


In each view type, you can refine the report criteria to filter out expected activity—the data you know 
about. You can filter this activity by refining the query criteria. These criteria should be tuned to a 
specific network. Reports can be valuable in detecting behaviors beyond the normal traffic flows of your 
network. You can determine the expected activities using reports that are not filtered and vetting those 
results against normal network use. 


MARS provides three view types, each of which restricts the matched sessions to a user-defined limit of 
N. The following view types exist: 
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e Total View. For each result type matching the query criteria, this view counts the occurrences of that 
result type that transpire during the specified time period. It presents the total count of the top NV 
matched result types, ranked by number of sessions, as determined by which ones occurred most 
frequently over the period of time. You can use these reports to determine your network’s condition 
relative to the studied sessions. For example, you can use this view to identify attacks that launched 
at frequent intervals. This view does not present spikes in network activity; it simply presents the 
top occurring result types. 


e Peak View. Within MARS, all report result data is stored in 10-minute time slices. The Peak View 
studies each of the 10-minute time slices within the specified time period to which one contained 
the highest number of matched sessions for a specific result type. It also determines an additional 
nine peaks within the time period, where each peak identifies a unique result type relative to the 
other peaks. 


Each peak value is charted relative to the other nine peaks. For each time slice containing a peak value, 
the Peak View lists the top N matched result types that occurred. It is possible to have multiple peaks 
within the same time slice, as it is the result type, not the time slice, that must be unique across peaks. 


Note To be detected within this view, the result type must peak above normal traffic. Therefore, you must tune 
the query data to filter out expected traffic. 


Unlike the Total View, the Peak View does not focus on the overall top occurring results, instead it 
identifies a high volume of traffic over a short time period. Its purpose is to detect temporary bursts of 
traffic on your network that overshadow normal traffic usage. These bursts identify possible issues, such 
as worm outbreaks. 


e Recent View. This view is similar to Total View; however, it identifies the top N result types that 
occurred within the past hour. It then plots all occurrences of those result types over the selected 
time period. 


e CSV. Generates the Total View but presents the report in the CSV format for processing by another 
tool or script. This option is intended for use with e-mail notifications where post-processing is 
required. 


Creating a Report 


You can create a report through the Query page, or you can create a report from scratch on the Reports 
page. These instructions detail creating a report from the Reports page, but are applicable to editing 
reports and to creating reports from the Query page. 


To Create a New Report 


Step 1 On the Reports page, click the Add button. 


Step2 Inthe Report Name and Report Description fields, enter a report name and description. Click the Next 
button. 


Step3 Select the schedule parameters for the report. 


Step4 Select a View Type for the report. You can receive these reports in your email or view them in the UI. 
Your choices are: Total View, Peak View, Recent View, and CSV (see Report Type Views: Total vs. 
Peak vs. Recent, page 20-23). Click the Next button. 


Step5 Select users in the Recipients Available field by expanding the user groups, clicking users or user groups, 
and clicking the Add button. See User Management, page 23-8 for more information. 
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Step 6 
Step7 


Step 8 


Reports Mi 


Repeat Step 5 for other users. Click the Next button. 


Build or modify the query. To edit the query time range, either click the Report type link or click the 
Edit button. See Result Format, page 20-5 for information on query parameters; see Query Criteria, page 
20-10 for more information on building queries. Click Apply to save your changes; click Next when the 
query is complete. 


Click Submit to save your report. 


Working With Existing Reports 


To View a Report 


Step 1 
Step 2 


Click the radio button next to the report. 

From the drop-down list on the bottom of the page, select either: 
- View HTML: to view the report as an HTML file. 
- View CSV: to view the report as a CSV file. 

Click the View Report button. 


To Run a Report 


Step 1 
Step 2 


wy 


If you chose to view the report as a CSV file, you need to save the file to your computer and open the 
CSV file in a third-party application. 


Click the radio button next to the report. 
Click the Run Now button. 


Note 


To Delete a Report 


Step 1 
Step 2 
Step 3 


Due to caching issues, reports with a time range of less than one hour are not recommended. 


See Table 20-1, “Maximum Database Retention Limits for Report Results” for information on how long 
report results are retained in the database per MARS model number. 


Click the radio button next to the report. 
Click the Delete button to delete the report. 


On the Delete Confirmation page, click Delete. 
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To Edit a Report 


Step 1 
Step 2 
Step 3 


You can not edit system generated reports. Editing report criteria is meant for minor tweaking to 
previously generated report. 


Click the radio button next to the report. 
Click the Edit button to edit the report. 


Navigate using the Previous and Next buttons, or clicking on the report criteria. 


Figure 20-26 Navigating to the Recipients column by clicking its criteria 


gy 
[Name _ [Schedule Format  |Recipients 
Test Run on demand only Norma? dm 8 
¢ 


Edit the report, and click the Apply button to apply changes to the report. 
Click the Submit button to finalize the report. 


Changing the report’s query criteria will not re-generate a new result. New edited criteria is based on the 
previously generated report. In some situation such as filtering out specific IP source, user should create 
a new report. 


Note 


Email notification of a global generated report will be sent from the Global Controller and not the 
Local Controller. 


User Guide for Cisco Security MARS Local Controller 
P20-26 I 78-17020-01 | 


Mle T 


Rules 


This chapter discusses MARS Inspection and Drop rules in the following sections: 
e Rules Overview, page 21-1 
e Constructing a Rule, page 21-5 
e Working with System and User Inspection Rules, page 21-17 
e Working with Drop Rules, page 21-21 
e Setting Alerts, page 21-23 
e Rule and Report Groups, page 21-24 


Rules Overview 


An inspection rule is a real-time filter that detects interesting patterns of network activity. These patterns 
can signify attacks or false positives, and they inform you of network configuration errors and other 
anomalous network behavior. An attack might be straightforward, or it could be a probe, an attack, and 
then a follow-up to the attack. Whatever the method of attack, attacks share common traits, and you can 
use rules to define these traits to identify and mitigate attacks. 


Rules create incidents. Rules connect the information you receive from your networks’ reporting 
devices, linking them together to form a chain of events that describes an unfolding intrusion. They 
classify incoming events as firing events by matching them against the rule criteria. They also determine 
when a false positive is either dropped completely or kept as information in the database. 


.A rule is either active or inactive. Active means the rule is operating and is being applied to incoming 
events. Inactive indicates that the rule is inoperative and not consuming CS-MARS resources. 


wy 


Note A rule cannot be deleted, it can be made active or inactive. 


Figure 21-1 shows a portion of the Inspection Rules page of the Rules tab. 
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Figure 21-1 Top Portion of Inspections Rules Page 


Cisco Systems 


SUMMARY || INCIDENTS |] QUERY / REPORTS [ruts | MANAGEMENT || ADMIN || HELP 
Inspection Rules |[ Drop Rules [00 Sep 1, 2005 9:40:26 AM EDT | 


Brus | CS-MARS Standalone: LC20-Doc v4.1 Login: Administrator (pnadmin) 3; | Logout | it | Activate 


Select Case: [No c 


Inspection Rules: 


Group: Jall Be view: [Active fl Edit Group Delete Group Add Group 
Edit Change Status Duplicate Add 
[Rule Name: System Rule: Backdoor: Active Status: Active 
Action: None Time Range: 9h:30m 
Description: This correlation rule detects a connection to a backdoor server or a response fram a backdoor server in your network accompanied by malicious follow-up activity on the server hosting 


the backdoor - this may indicate that a malicious backdoor service is likely running in your network. Maliciaus follow-up activity includes excessive scans, denied packets, installation of 
malicious services, local buffer overflow attacks etc, Backdoors such as Unix rootkits or Trojan horses are malicious programs that offer extensive remote control of a host and may be 
left by an attacker on a compromised host to maintain future remote access. 


Offset|Open ( |Source IP |Destination IP|Service Name Event Device|Reported|Keyword|Severity|Count| ) Close|Operation 
User 
a ( ANY SAME, ANY ANY — None ANY ANY il OR 
$TARGETO1, 
ANY tral 
Penetrate/' 
Penetrai pp/Connect 
2 SAME, ANY ANY pp/Response, ANY None ANY ANY 1 ) FOLLOWED- 
$TARGETOL, , BY 
ANY 
(¢ SAME, DISTINCT, SAME_ANY_DEST_PORT ANY — None ANY ANY 25 OR 
$TARGETO1, ANY FirewallPoli jon/ACL, 
ANY FirewallPoli jation/NAT 
4 SAME, ANY ANY ANY — None ANY ANY 1 ) OR 
$TARGETOL, 
ANY 
rtChannel ~ 
5 ANY SAME, ANY All, ANY — None ANY ANY az ) 4 
$TARGETO1, Penetrate/Backdoor/CovertChannel rr) 
ANY T+ 
= 


Prioritizing and Identifying 


Your first order of business is to prioritize your network’s assets; in other words, figure out what is going 
to cost you the most money if it goes down. Next, identify your networks’ most exploitable weaknesses. 
Choose which ones you are willing and able to close, and rank the remaining weaknesses by risk and 
exploitability. 


Use this ranked list to guide your time and energy expenditures when customizing the CS-MARS rule 
set. 


Think Like a Black Hat 


Ignore for a moment the benign users who do legitimate business on your networks. 


Get inside the mind of the black hat that wants to take your network down. The person who should 
concern you is the one with a plan. 


Good plans have a sequence of steps, contingencies, and metrics to determine success or failure. The 
more fully you can anticipate these plans, the fewer attacks will be able to execute unhindered and 
unobserved. The black hat is looking for wide-open doors and easy access. Failing that, the black hat is 
going to look for specific and obvious exploitable weaknesses. 


Planning an Attack 


Start to detail your plan. You want to penetrate a network. You’d like to avoid detection and identification 
if possible. You want root access on a host. 
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How do you get root access? You do not have a preexisting account, and physical access isn’t feasible. 
The first few options that come to mind are password guessing, password brute force, or exploiting a 
known weakness on the host. 


You decide to exploit services running on the host, so you need to find out what it is running. To do this, 
you have a number of techniques: port scans, OS fingerprinting, banner probing, etc. 


Once you’ve identified a vulnerable service or software, you can attack it with a catalogue of exploit 
software. Depending on what you find and your available exploits, there are a number of different 
effects, usually allowing you to execute arbitrary code. 


You now own the host. What happens next is up to you. You have many options: you can install a root 
kit, you can crash the machine, etc. You have full access—you can do just about anything on to/from that 
host. 


Back to Being the Admin 


Step 1 


Step 2 


Step 3 


You must now express the plan in terms of information that is reported to you. This attack plan contains 
an attack with a follow up of some kind. You might write your plan like: 


e probe 
e attacker to target, buffer overflow 
e attacker to target, root login (compromised host) 


At this point, the black hat has compromised the host. What happens next is up to the attacker. This 
makes the next few steps especially hard to predict. They want to be able to manipulate the world, they 
want to make change. Your newly compromised host is the instrument for change. You can specify 
additional potential steps in the plan that make it even more urgent to take care of the situation 
immediately. Such as: 


e target to FTP server, code download 
e target to secondary target, buffer overflow 
The attacker is now using your compromised host as a launching point for further attacks. 


One you’ve mapped out the anticipated attack to watch for, you can define a monitoring plan. The 
following task flow outlines the tasks involved in implementing a monitoring plan: 


Ensure your reporting devices are providing all the data you need. This step involves ensuring that each 
device is generating logs about the events that you expect to occur as the result of the probes and attacks. 
Depending on the device type, this can involve several substeps, such as specify a logging level, enable 
logging for the specific event, and ensuring that the reporting device publishes events to the 

Local Controller appliance. It can also involve enabling administrative access to the reporting device 
from the Local Controller appliance. 


Configure CS-MARS to pull events from the reporting devices on your network. This step involves 
adding each reporting device to Local Controller. If the reporting device type is not directly supported, 
you must define a custom device type for the reporting device. To add a supported reporting device, see 
Adding Reporting and Mitigation Devices, page 2-16. To define a custom device type, see Adding User 
Defined Log Parser Templates, page 15-1 and To add a custom Device/Application type:, page 15-1. 


Ensure that the event types that you need to study are accepted and processed by Local Controller. If 
they are not, you must define a custom log parser template for each event and a custom device template 
to which the custom log parser templates are associated. For device types supported by CS-MARS, this 
should not be necessary. To define a new parser template, see Adding User Defined Log Parser 
Templates, page 15-1 and To add Parser Templates for a Device/Application, page 15-3. 
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Note 


Step 4 


You cannot define a custom log parser template for a reporting device that is supported out of the box. 
In this case, to define log parser for an unsupported event type, you must still define a custom device 
type before you can define the log parser. 


Check to see if a system rule will capture the information that you want, otherwise write your own user 
inspection rule. Define user inspection rules that monitor for the event types and correlate those events 
into a structure that will help you identify the incident. You can also specify who should be notified and 
how if the rule fires. 


Types of Rules 


wy 


Note 


Inspection Rules 


A rule cannot be deleted, it can be made active or inactive. 


An inspection rule states the logic by which the CS-MARS tests whether or not a single network event 
or series of events is a noteworthy incident. An event or series of events with attributes that match the 
attributes specified in an inspection rule causes the rule to trigger (or “fire”) to create an incident. 
Incidents may be attacks, network configuration errors, false positives, or just anomalous network 
activity. The over 100 inspection rules that ship with MARS are called System Inspection Rules. The 
number and structure of system rules are updated in signature upgrades and with more recent software 
releases. Both types of upgrades are performed from the Admin > System Maintenance > Upgrade page. 


You can create custom inspection rules by editing or duplicating system inspection rules, by adding your 
own from the Inspection Rules page, or by using the Query interface. Customized inspection rules are 
called User Inspection Rules and are displayed on the Inspection Rules page. 


Inspection rules can be created on both the Global Controller and the Local Controllers. 


Global User Inspection Rules 


Drop Rules 


Global Inspection Rules are inspection rules you create on a Global Controller then push to the 

Local Controller. From the Local Controller, you can edit only the Source IP Address, Destination IP 
Address, and Action fields of a Global Inspection Rule. To change the arguments of the other fields, you 
must edit the rule on the Global Controller. When you edit a global inspection rule on the 

Local Controller then edit it again on the Global Controller, the Global Controller version overwrites the 
Local Controller version. Global Inspection rule names are displayed with the prefix “Global Rule.” 


Drop rules allow false positive tuning on a MARS, and are defined only on the Local Controller Drop 
Rules page. They allow you to refine the inspected event stream by specifying events and streams to be 
ignored and whether those data should be stored in the database or discarded entirely. Drop rules are 
applied to events as they come in from a reporting device, after they have been parsed and before they 
have been sessionized. Events that match active drop rules are not used to construct incidents. Because 
the Global Controller does not receive events from reporting devices, rather it receives them from 
Local Controllers, you cannot define drop rules for the Global Controller. 
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Constructing a Rule 


Each step of your plan corresponds to a line of a rule. Each line identifies a set of conditions. A rule can 
have a single line, two lines, or multiple lines. You link these lines together using the logical operators, 
“AND, OR, FOLLOWED-BY (in time).” 


For more information on the conditions and operators found in a rule, see Table 21-1 on page 21-6. 


The first step of the example plan, identified in Back to Being the Admin, page 21-3, involved probing 
the target host. You can express a probe by selecting the appropriate event type groups as the line’s event 
type criteria. Also, you want to use dollar variables ($TARGET)! to constrain your host to ensure that 


For more information on the conditions and operators found in a rule, see Table 21-1. 


The first step of the example plan, identified in the section Back to Being the Admin, page 21-3, involved 
probing the target host. You can express a probe by selecting the appropriate event type groups as the 
line’s event type criteria. Also, you want to use dollar variables ($STARGET)’ to constrain your host to 
ensure that the probe and attacks that are reported have happened to the same host. Then you need to 
figure out the logical step for the next line. In this case, the probe could be optional depending on the 
time frame that the probe was sent and its subtlety. 


Rule logic is simple. You have a row. Every row has cells. 'The logical expressions connecting different 
cells are “and,” while the expressions connecting items inside a cell are either “or” or “and not’, 
depending which clause is chosen—the equal to or not equal to. 


By studying the system inspection rules, you can identify three commonly used rules: attempts, success 
likely, and failures, The most common rule structure is the basic three-line rule that identifies an 
attempted attack. It is expressed as: 

(Probe AND 

Attack) OR 

Attack) 


Note 


To clarify this pseudocode, keep in mind that uppercase AND, OR and FOLLOWED-BY identify a 
logical operator between two rule lines. Lowercase “and” identifies a logical operator between two cells. 
Lowercase “or” and “and not” identify a logical operator between two items within a cell. 


Success likely rules extend the attempt rules by identifying suspicious activities originating from the 
attacked host. The general structure of these rules is: 


((Probe AND 

Attack) OR 

Attack)) FOLLOWED BY 

(Suspicious Activity[1]..Suspicious Activity[n] ) 

Failures identify an event from a reporting device that the device classifies as a failure. Often, these rules 
simply match to known syslog or SNMP messages indicating some failure on the device. You can define 


alerts to keep you abreast of device failures. These rules follow one of two general structures: a one line 
failure— 


1. A variable, such as ($TARGET), serves two purposes in the rule: 1.) It captures the number of times the same cell value is 
matched upon—the count for that cell, e.g., ten login failures from the same source address. 2.) It correlates the same value 
of a cell across rule lines, e.g., a probe from a source address AND an attack from that same source address. 


2. A variable, such as (S$TARGET), serves two purposes in the rule: 1.) It captures the number of times the same cell value is 
matched upon—the count for that cell, e.g., ten login failures from the same source address. 2.) It correlates the same value 
of a cell across rule lines, e.g., a probe from a source address AND an attack from that same source address. 
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Failure 


—or multi-line failures separated by the OR operator— 


1..N Failure OR 


Failure 


In the HTML interface, system rules are displayed in rows and columns. The row number is called the 
Offset. A rule can have more than one row (or offset), as shown in Figure 21-2. 


Figure 21-2 


al Rule Name: 
Action: 
Description: 


Rule with Multiple Offsets 


System Rule: Backdoor: Active 


None 


Status: Active 


Time Range: Sh:30m 

This correlation rule detects a connection to a backdoor server or a response from a backdoor server in your network accompanied by malicious follow-up activity on the server hosting 
the backdoor - this may indicate that a malicious backdoor service is likely running in your network, Malicious follow-up activity includes excessive scans, denied packets, installation of 
malicious services, local buffer overflow attacks etc. Backdoors such as Unix rootkits or Trojan horses are malicious programs that offer extensive remote control of a host and may be 
left by an attacker on a compromised host to maintain future remote access. 


Offset/Open ( |Source IP |Destination IP|Service Name Event Device|Reported|Keyword|Severity|Count! ) Close|Operation 
User 
1 ¢ ANY SAME, ANY ANY None ANY ANY vf OR 
$TARGETO1, 
ANY 
2 SAME, ANY ANY » ANY — None ANY ANY 1 ) FOLLOWED- 
$TARGETO1, BY 
ANY 
(¢ SAME, DISTINCT, SAME_ANY_DEST_PORT ANY None ANY ANY 25 OR 
$TARGETO1, ANY 
ANY 
4 SAME, ANY ANY ANY None ANY ANY 1 } OR 
$TARGETO1, 
ANY 
rtChannel Se 
5 ANY SAME, ANY ANY None ANY ANY a } t 
$TARGETO1, Penetrate/Backdo rtChannel by 
ANY ~~ 


Table 21-1 
Rule Field 


Rule Fields and Argruments 


Field Description and Arguments 


Argument Descriptions 


Offset 


The row number. 


Open ( 


Identifies the open of a clause. 
Clauses are used to compare one or 


more compound conditions in a rule. 


Displays the open braces you create a 


clauses. 
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Table 21-1 Rule Fields and Argruments 
Rule Field Field Description and Arguments Argument Descriptions 
Source IP IP address of the packet originator. 


Variables 


ANY—(Default). Signifies that the 
IP address for each count is any IP 
address. 


SAME—Signifies that the IP address 
for each count is the same IP address. 
This variable is local to its offset. 


DISTINCT— Signifies that the IP 
address for each count is a unique IP 
address. This variable is local to its 
offset. 


$TargetOl to $Target20—The same 
variable in another field or offset 
signifies that the IP address for each 
count is the same IP address. 


Network Groups 


Defined network groups— 
Topologically valid network groups as 
defined under Management > IP 
Management. 


Networks Topologically valid network groups as 
defined under Management > IP 
Management. 

Devices The hosts and reporting devices 
present in the system. 

IP addresses IP addresses present on devices in the 
system or user entered dotted quads. 

IP ranges The range of addresses between two 


dotted quads. 
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Table 21-1 Rule Fields and Argruments 


Rule Field Field Description and Arguments Argument Descriptions 


Destination IP IP address of the packet destination. Often referred to as the target. 


Variables ANY—(Default). Signifies that the 
IP address for each count is any IP 
address. 


SAME—Signifies that the IP address 
for each count is the same IP address. 
This variable is local to its offset. 


DISTINCT—Signifies that the IP 
address for each count is a unique IP 
address. This variable is local to its 
offset. 


$TargetOl to $Target20—The same 
variable in another field or offset 
signifies that the IP address for each 
count is the same IP address. 


Network Groups— Defined network groups— 
Topologically valid network groups as 
defined under Management > IP 
Management. 


Networks— Topologically valid network groups as 
defined under Management > IP 
Management. 


Devices—The hosts and reporting |The hosts and reporting devices 
devices present in the system. present in the system. 


IP addresses— IP addresses present on devices in the 
system or user entered dotted quads. 


IP ranges—The range of addresses |The range of addresses between two 
between two dotted quads. dotted quads. 


Service Name A TCP/IP-based network service, identified by protocol and port, defined 
within the packet. 
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Rule Fields and Argruments 


Field Description and Arguments 


Constructing a Rule 


Argument Descriptions 


Variables 


ANY—(Default) No constraint is 
placed on the source or destination 
ports or protocol or port. 


SAME type variables signify that the 
specified destination port, source port 
and protocol are the same for each 
count. These variables are local to the 
offset. 


e SAME_ANY_DEST_PORT 
SAME_TCP_DEST_PORT 
SAME_UDP_DEST_PORT 


e SAME_ANY_SRC_PORT 
SAME_TCP_SRC_PORT 
SAME_UDP_SRC_PORT 


DISTINCT type variables signify that 
the specified destination port, source 
port and protocol are unique for each 
count. These variables are local to the 
offset. 


e DISTINCT_ANY_DEST_PORT 
DISTINCT_TCP_DEST_PORT 
DISTINCT_UDP_DEST_PORT 


Identical variables in different fields 
or offsets signify that the specified 
port and protocol for each count are 
identical to each other. 


e $ANY_BOTH_PORTS5 


e $ANY_DEST_PORT1 to 
ANY_DEST_PORTS5 


e $ANY_SRC_PORT1 


e¢ $TCP_BOTH_PORT1, 
$TCP_BOTH_PORT2 


e $TCP_DEST_PORTI to 
$TCP_DEST_PORTS5 


e $TCP_SRC_PORT1, 
$TCP_SRC_PORT2 


e $UDP_BOTH_PORT1, 
$UDP_BOTH_PORT2 


e $UDP_DEST_PORT1 to 
$UDP_DEST_PORT5 


¢ $UDP_SRC_PORTI, 
$UDP_SRC_PORT2 
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Rule Field 


Rule Fields and Argruments 


Field Description and Arguments 


Argument Descriptions 


Defined services—One or more 
services defined under 
Management > Service 
Management. 


Service groups—One or more 
service groups defined under 
Management > Service 
Management. 


e Backdoor 

e Instant Messaging 
e Mail Retrieval 

e Online Game 

e P2P 

e Recent Backdoor 
e TCP-highport 

e UDP-highport 


e vulnerable-protocols 


Event 


Identifies one or more event types. An event type indicates some type of 
network activity or condition. Sometimes, events reported from different 
devices and different device types identify the same activity or condition, and 
therefore, they map to the same event type within MARS. Event types are 
sorted into event groups, such as “Probe/PortSweep/Stealth”, to catch any of 
the network conditions identified by the group. 


Variables—Signify any single event 
type defined under Management > 
Event Management, only useful for 
lines in tandem with the same 
variable. 


e ANY—Any of the active event 
types can match this rule. 


e¢ SAME 
e DISTINCT 


e $EVENT_TYPEO1, 
$EVENT_TYPE10 


Event types—Events that have been 
merged into types. 


Event type groups—Groups of 
event types. 


e ANY 

e SAME 

e DISTINCT 
e All events 
e ANY 

e SAME 

e DISTINCT 


Red Severity Event 
Types—Displays all severe event 


types 


Yellow Severity Event 
Types—Displays all yellow event 


types 
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Rule Field Field Description and Arguments Argument Descriptions 
Green Severity Event 
Types—Displays all green event 
types 

Device The value of this condition can be one of the following: 


Variables—Signify any single 
device defined under Admin > 


System Management > Security and 


Monitor Devices, only useful for 
lines in tandem with the same 
variable. 


ANY—(Default) Specifies that 
this rule is applied to events 
generated by any of the reporting 
devices defined in MARS. 


SAME 
DISTINCT 


Unknown Reporting 
Device—Specifies that this rule is 
applied to events generated by any 
reporting device that is not 
defined in MARS. 


$DEVICEO01 to $DEVICE10 


e Reporting Devices—lIdentifies 
one or more hosts or reporting 
devices for which events are 
inspected. Valid values are one 
or more devices as defined 
under Admin > System Setup > 
Security and Monitor Devices. 


Defined Device Types— 


Reported User 


Identifies the active user on the host 


when this event was recorded. Not 
all events include this data. The 


value of this condition can be one of 


the following: 


ANY—No constraint is placed on 
the reported user. 


NONE— (Default) Specifies that 
this condition should not be used 
to match this rule. 


Variables—Signify any single 
user, only useful for lines in 
tandem with the same variable. 


Invalid User Name—Specifies 
that this condition is met when the 
user name reported is invalid. 
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Rule Field 


Rule Fields and Argruments 


Field Description and Arguments 


Argument Descriptions 


Severity 


The value of this condition can be 
one of the following: 


e ANY—(Default) Specifies that 
this rule is applied to events of all 
severity levels. 


e Green—Restricts this rule to 
firing against low-severity events. 


e Yellow—Restricts this rule to 
firing against medium-severity 
events. 


e Red—Restricts this rule to firing 
against high-severity events. 


Count 


Identifies the number of items the 
event must occur before the 
condition is met. The value for this 
condition is a whole number ranging 
between 1 and 100. The default 
value is 1. 


wy 


Note Events of the same event 
type occurring in the same 
session in a three-second 
period increment the active 
count by one. This inherent 
threshold ensures that a 
event floods of the same 
type does not increase the 
active count arbitrarily and 
incorrectly fire the rule. 


Example usage: When a backdoor 
rootkit install is detected, the count 
should be | as it is only going to be 
reported once and it is not something 
you expect to ever see on your 
network. However, if you are using 
deny messages to detect infected 
hosts, you may want the count value to 
be higher. For example, you may want 
to allow for several common mistakes, 
such as password failures, before 
firing a rule for the event. People 
accidentally mistype passwords, they 
don’t accidentally install a rootkit. 


Close 


Identifies the close of a clause. 


| User Guide for Cisco Security MARS Local Controller 


78-17020-01 | 


| Chapter21 Rules 


Constructing a Rule 


Table 21-1 Rule Fields and Argruments 

Rule Field Field Description and Arguments Argument Descriptions 

Operation The value of this field can be one of | ¢ None—(Default) Defines a 
the following: single-line rule or a simple 


condition. 


e AND—A boolean “and” used to 
construct a compound condition 
(two or more lines). This line and 
the next line must both be 
satisfied before the compound 
condition is met. 


¢ OR—A boolean “or” used to 
construct a compound condition 
(two or more lines). Either this 
line or the next line can be 
satisfied to meet the compound 
condition. 


¢ FOLLOWED-BY—lIdentifies a 
compound condition (two or more 
lines). specifically a sequential 
order of occurrence. Also referred 
to as a time conditional rule (e.g., 
Y must happen after X).The 
condition of this line must be met, 
and then the condition of the next 
line must be met before the 
compound condition is met. 
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Rule Field 


Rule Fields and Argruments 


Field Description and Arguments 


Argument Descriptions 


Time Range 


Identifies the period of time over 
which the count value is augmented. 
For rules that have a Count value 
greater than one, the Time Range 
value determines how long the 
period should be before the count 
value is reset. For example, you can 
assume that if no more than three 
login attempts have occurred over a 
10-minute period that counter can be 
reset. 


Usage Guidline: The Time Range 
value combined with the Count value 
can affect the operation of your 
MARS. Each time an event is captured 
that satisfied a unique instance of an 
inspection rule, a monitoring session 
is constructed to track possible future 
occurrences until either the Count 
value is reached or the time period 
expires. 
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Table 21-1 Rule Fields and Argruments 
Rule Field Field Description and Arguments Argument Descriptions 
Action Identifies the action that MARS will | ¢ NONE—(Default) This action 


take when the rule is fired. Actions 
are user-defined alerts that include 
an action name and description, 
which also doubles at the message 
text provided in the alert. Each 
action can combine alert techniques, 
such as email and syslog. Each alert 
technique can have multiple values. 
For example, an action can generate 
two emails, a page, and a SNMP 
trap. Each rule can have multiple 
such actions. Alerts can be 
constructed using one or more of the 
following techniques: 


S 


Note You will see the column 
Action/Operation. In this 
case, you can select either 
one of the following actions 
or one of the operators . 


states that no further action will 
be taken. When NONE value is 
selected, the firing of the rule 
causes an event record to be 
created and stored in MARS. 
Regardless of the selected action, 
this record is always created. 


e Email—lIdentifies the list of 
administrators to whom an alert 
should be sent. An e-mail address 
must be defined for the selected 
administrators. 


e Syslog—lIdentifies the list of 
hosts to whom an alert should be 
sent. You can select any number 
of devices to which you want a 
syslog message sent. 


e Page—lIdentifies the list of 
administrators to whom an alert 
should be sent. The message 
format is text. A pager number 
must be defined for the selected 
administrators. 


¢ SNMP —Lists the hosts to which 
a Simple Network Management 
Protocol (SNMP) alert can be 
sent. 


e SMS—List of users to receive 
notification by Short Message 
Service (SMS). The message can 
be up to 160 characters. An SMS 
number must be ten numbers and 
a domain name, for example, 
1234567890 @ provider.com. 


e Distributed Threat Mitigation 
(DTM)— Lists the Cisco IOS 
Intrusion Prevention System (IPS) 
devices to which an IPS alert 
action can be sent (alarm, alarm 
and drop, or alarm and reset if it is 
a TCP session.) See the 
Technology Preview: Configuring 
Distributed Threat Mitigation 
with Intrusion Prevention System 
in Cisco Security MARS, page | 
document for DTM configuration 
information. 
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Working Examples 


The examples in this section demonstrate the use of variables, in particular, how to use variables to detect 
Deny patterns. 


Note We recommend that you study the system inspection rules for more complex examples. 


Note For a single offset rule, the variables SAME and SAME_ANY_DEST_PORT can be substituted in any 
of the examples for $TARGETO1 and $ANY_DEST_PORT1, respectively. The “ANY” in 
$ANY_DEST_PORT1 means either UDP or TCP protocol. 


Example A: Excessive Denies to a Particular Port on the Same Host 


Figure 21-3 Rule for Excessive Denies to a Particular Port on the Same Host 
[- Rule Name: Example A Status: Active 
Action: Time Range: Ohh:O0mm:10ss 
Description: Excessive denies to a particular port on the same host, o 
Offset[open ( |Source IP [Destination 1P|Service Name [Event [Device| Severity |Counts|Zone | ) Close|Operation 3 
al ANY $TARGETOL $ANY_DEST_PORT1 FirewallPolicyViolation/ACL ANY ANY 100 Training al 


In this example, the rule fires when 100 of the specified events occur from any source IP address to the 
same destination IP address, and the destination port numbers are identical. 


Example B: Same Source Causing Excessive Denies on a Particular Port 


Figure 21-4 Rule for Same Source Doing Excessive Denies on a Particular Port 
T Rule Name: Example B Status: Active 
Action: Time Range: Shh:0mm:10ss 
Description: Same source doing excessive denies on a particular port. mn 
Offset|Open ( [Source IP [Destination 1P|Service Name |Event [Device|Severity|Counts|Zone | ) Close|Operation |S 
1 $TARGETO1 ANY $ANY_DEST_PORT1 FirewallPolicyViolation/ACL ANY ANY 100 Training ae 


In this example, the rule fires when 100 of the specified events occur that have the source IP address, 
any Destination IP address, and identical destination port numbers. 


Example C: Same Host, Same Destination, Same Port Denied 


Figure 21-5 Rule for Same Host, Destination, Same Port Denied 
| Rule Name: Example C Status: Active 
Action: Time Range: Shh:0mm:10ss 
Description: Same host, destination, same port getting denied. S 
Offset|Open ( [Source IP [Destination IP|Service Name |Event [Device|Severity|Counts|Zone | } Close|Operation = 
1 $TARGETO1 $TARGETO2 $4NY_DEST_PORT1 FirewallPolicyViolation/ACL ANY ANY 20 Training pal 


In this example, the rule fires when 20 of the specified events occur that have the same source and 
destination addresses, and identical destination port numbers. 
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Working with System and User Inspection Rules 


Navigate to the Rules page by clicking the Rules tab. From this tab, you can access the 
System Inspection Rules and Drop Rules tabs. 


You can perform the following actions with System Inspection rules: 
e Change the Source IP, Destination IP and Device arguments of system rules 
e Duplicate system rules 
e Create (Add), delete and edit your own rules (user rules) 
e Toggle the state of the rules between active and inactive 


e Add, edit, or delete a rule group 


Note 


Upgrade the MARS software regularly to obtain new and updated System Inspection rules. For more 
information, see the Install and Setup Guide for Cisco Security Monitoring, Analysis, and Response 
System. 


Note 


When you edit a rule, you must click Activate to enable the changes. 


Change Rule Status—Active and Inactive 


wy 


The CS-MARS correlation engine continuously tests only active rule criteria against incoming events to 
identify incidents. Inactive rules do not consume resources used for realtime operations. 


Note 


Step 1 
Step 2 
Step 3 


Step 4 


A rule cannot be deleted, it can be made active or inactive. 


To change the status of a rule, follow these steps: 


Navigate to the Rules > Inspection Rules page. 
Select the checkbox of the rule (or rules) to change. 


Click Change Status. 
The selected rules are made inactive if active, and active if inactive and displayed on a different page. 


To display inactive rules, select Inactive from the View dropdown list. To display active rules, select 
Active. 


Duplicate a Rule 


Duplicating a rule creates a new rule that is a copy of an existing system or user inspection rule. You can 
edit all of the fields of a duplicate rule, but only the Source IP, Destination IP, and Device fields of a 
system inspection rule. The original rule is left unchanged after duplication. 
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Note 


Step 1 
Step 2 


Edit a Rule 


You cannot delete a rule after it is created by Duplicate or Add. 


To duplicate a rule, follow these steps: 


Select the checkbox of the rule to duplicate. 


Click Duplicate. 

The name of duplicated rule is the name of the original rule extended with a timestamp of when the 
original was duplicated (for example, System Rule: Client Exploit - Sasser Worm Copied: 
05.10.05/16:54:21). The name can be changed by editing the duplicate rule. 


You can edit rules with inline editing, or with the rule wizard. To edit inline, you click the argument to 
edit. The rule wizard is invoked by selecting a rule to edit then clicking Edit. The rule wizard begins 
with the Rule Name field and progress through each subsequent field. 


You only edit the Source IP, Destination IP, and Device fields of a system inspection rule. See Duplicate 
a Rule, page 21-17 for further information on modifying system inspection rules. 


Step 1 


Step 2 
Step 3 
Step 4 


Step 5 


Step 1 


A rule cannot be deleted, it can be made active or inactive. 


Edit a Rule with Inline Editing 


You can perfom inline editing to rules from the Incidents Detail page, or from the Inspections Rules 
page. To edit a rule with the Inline Editing, follow these steps: 


Click the Rule argument that you want to edit. 
The edit page for the selected field appears. 


Change the argument, then click Apply. 
Repeat Step | as required. 


Add Open and Close parentheses as required then click Submit. 
If no parentheses are required, just click Submit. 


Click Activate to include the rule in event correlation processing. 


Edit a Rule with the Rule Wizard 


The Rule Wizard can only be invoked from the Inspections Rule page. 


To edit a rule with the Rule Wizard, follow these steps: 


Select the check box of the rule to edit. 
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Step2 Click Edit. 
The rule wizard page appears for the Rule Name field. 
Step3 Do one of the following actions: 
e Change the argument of the field, then click Apply. Proceed to Step 6. 
e Change the argument, then click Next to proceed to the next field. 
e Click Next to proceed to the next field without changing the argument. 
e Click Previous to go back to the previous field. 
Previous does not appear for the Rule Name page. 
Step4 Repeat ° as required. 
Step5 Click Apply after making all edits. 
Tip To skip to the end, click the Count argument, after which, only the Action, and Time Range 
fields must be reviewed. 
Step6 Add Open and Close parentheses as required then click Submit. 
If no parentheses are required, just click Submit. 
Step7 Click Activate to include the rule in event correlation processing. 


Add an Inspection Rule 


\ 


Note 


Step 1 
Step 2 
Step 3 


Step 4 


Rules that you add are called User Inspection Rules. 


Navigate to the Inspection Rules page. 


Click Add. 


Enter a name and description for the rule, then click Next. 


Select Source IP address . 
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Figure 21-6 User Inspection Rule Creation Form 
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The following numbers correspond to the numbers shown in Figure 21-6. 


1. 


10. 


Check the boxes next to the items in the Sources Selected field to select them, and click the Toggle 
Equal button to change them between equal and not equal. 


Click the Select All button to select all items in the Sources Selected field. Items selected in the 
Sources Selected field are deselected when you click Select All. 


Use the Equal and Not Equal buttons to bring highlighted items from the Sources Available field 
into the Sources Selected field. 


Filter sources from this drop-down list. 


Enter search text, and click Enter to move items that match the search criteria from the Sources 
Available field to the Sources Selected field. 


To add a new item to the sources, click the Add button. To edit or delete an existing source, click 
the Edit or Delete button. 


Click an item or items in the Sources Selected field, and use the Remove button. 


To move IP values up into the Sources Selected field, click the Equal up icon, or the 
Not Equal up icon. 


Check the radio button next to IP or Range, and enter an IP address or a range of IP addresses into 
their respective fields. 


Select items in the Sources Selected field by clicking them. Enter a group name, and click the 
Grouped As button to group them. 


Step5 = Follow the wizard, and select the values for the rule, clicking the Next button to progress to the next step. 


Step6 = When you are asked, “Are you done defining the rule conditions,” you can: 


- Click the Yes button for a single line rule. Continue to add repetition requirements (counts), 
alert information, and valid time ranges for each line. 
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- Click the No button, to create a multi-line rule that uses an operator (OR, AND, or FOLLOWED 
BY). Return to Step 4 and continue to make your selections. Continue to add rule information, 
and click Submit when finished. 


- Click the Submit button when finished. 


When the rule is complete, you need to activate it by clicking the Activate button. 


Figure 21-7 Clicking the Activate button 
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Note 


If you are creating or editing several rules, it is better for the system to click the Activate button for 
several changes rather than for each individual change. 


Working with Drop Rules 


Navigate to the Drop Rules page by clicking the Rules > Drop Rules tabs. 


Drop rules instruct the MARS to either drop a false positive completely from the appliance, or to keep 
it in the database. On the Drop Rules page, you add, edit, duplicate, activate an inactive rule, or inactivate 
an active rule. Inactive rules do not fire. 


While working with drop rules is similar to working with inspection rules, it is not identical. 


Change Drop Rule Status— Active and Inactive 


Step 1 
Step 2 


Step 3 


Check the box next to the rule. 
Click Change Status. 
When you change the status to inactive, the rule displays only on the inactive rules page. 


To display inactive Drop Rules, select Inactive from the View dropdown list. 


Duplicate a Drop Rule 


Step 1 
Step 2 


Check the box next to the rule. 
Click the Duplicate. 


After duplicating a rule, you can edit the duplicat without altering the original. 
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Edit a Drop Rule 


Step 1 Check the box next to the rule. 

Step2 Click Edit on the field that you want to change. 

Step3 = Follow the rule’s wizard and complete any other changes to the rule. 
Step4 Click Submit. 


SX 


Note When the rule or rules are complete, click Activate. 


Add a Drop Rule 


Step 1 Click Add. 
Step2 | Enter a name and description for the rule, and click Next. 


Step3 Select your sources. 


Figure 21-8 Drop Rule Creation Form 
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The following numbers correspond to the numbers in the Drop Rule Creation Form as shown in 
Figure 21-8: 


1. Check the boxes next to the items in the Sources Selected field to select them, and click the Toggle 
Equal button to change them between equal and not equal. 
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Step 6 
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2. Click the Select All button to select all items in the Sources Selected field. (Note: if you have items 
highlighted in the Sources Selected field, clicking Select All will de-select them.) 


3. Use the Equal and Not Equal buttons to bring highlighted items from the Sources Available field 
into the Sources Selected field. 


4. Filter sources from this drop-down list. 


5. Enter search text, and click Enter to move items that match the search criteria from the Sources 
Available field to the Sources Selected field. 


6. To add a new item to the sources, click the Add button. To edit or delete an existing source, click 
the Edit or Delete button. See IP Management, page 23-3 for more information. 


7. Click an item or items in the Sources Selected field, and use the Remove button. 


8. To move IP values up into the Sources Selected field, click the Equal | & == | (Up) icon, or the Not 
Equal &!= | (Up) icon. 

9. Check the radio button next to IP or Range, and enter an IP address or a range of IP addresses into 
their respective fields. 


10. Select items in the Sources Selected field by clicking them. Enter a group name, and click the 
Grouped As button to group them. 


Follow the wizard, and select the values for the rule, clicking the Next button to progress to the next step. 
When you are asked, “Are you done defining the rule conditions,” click the Submit button. 


When the rule is complete, you need to activate it by clicking the Activate button. 


Figure 21-9 Clicking the Activate button 
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Note 


If you are creating or editing several rules, it is better for the system to click the Activate button for 
several changes rather than for each individual change. 


Setting Alerts 


You have two options for learning about rules that have fired: you can log in and view the appropriate 
pages in the HTML interface or you can have MARS send alerts to external devices and users. Actions 
provide instructions to MARS on the second method. 


Using Rules, you can alert a person if a rule has fired. The roles and groups you can choose are 
determined by the information you have entered in User Management. for more information on adding 
users into the Local Controller. 
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Configure an Alert for an Existing Rule 


Step 1 
Step 2 
Step 3 
Step 4 
Step 5 


wy 


Click on a rule argument. 

Click Next until the Action/Operation column is selected. 

Click the Add button to add users for an alert. 

Enter a Name and Description for the notification. 

Check the box next to the type of notification that you want to send. Your choices are: 
e Email - select the roles or groups that you want to receive an email. 
e Syslog — select the systems that you want to receive the syslogs. 


e Page - select the roles or groups that you want to receive an electronic page on their pagers or 
cellular telephones. 


e SNMP - select the systems that you want to receive the SNMP trap information. 


Note 


Step 6 


Step7 


Step 8 
Step 9 
Step 10 


wy 


Note 


For SNMP and Syslog, you need to configure the receiving systems for this feature to work. 


Click the Change Recipient button to add or edit recipients for alerts for that notification type (email, 
syslog, page, or SNMP). 


Check the box next to the role, group, or system that you want to receive alerts. 
e Click the Add button to select recipients (to move them into the left field.) 


e To remove recipients, click their names to highlight them (in the left field) and click the Remove 
button. 


Repeat steps 5 - 7 for all the alert selections that you want to include. 
Click the Submit button. 
Click the Apply button. 


If a user adds an alert to a rule created on the Global Controller, and the rule is pushed down and fired 
on the Local Controller, the designated user receives the alert from the Local Controller and not the 
Global Controller 


Rule and Report Groups 


This section contains the following subsections: 
e Rule and Report Group Overview, page 21-25 
e¢ Global Controller and Local Controller Restrictions for Rule and Report Groups, page 21-26 
e Add, Modify, and Delete a Rule Group, page 21-26 
e Add, Modify, and Delete a Report Group, page 21-29 
e Display Incidents Related to a Rule Group, page 21-31 
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e Create Query Criteria with Report Groups, page 21-32 
e Using Rule Groups in Query Criteria, page 21-33 


Rule and Report Group Overview 


Rule and report groups help you manage rules and reports by speeding access to those rules and reports 
relevant to your task at hand. You can create groups, or use the groups provided with CS-MARS (System 
groups). Groups act as filters to limit the display of rules, reports, and incidents in the CS-MARS HTML 
interface. All groups can be modified or deleted. 


CS-MARS provides over 100 system rules and 150 system reports. More can be added by creating 
custom rules and reports, and by performing periodic software updates. A rule or report group contains 
a subset of these rules or reports as members. Usually rules or reports within the same group have related 
functions (such as, reconnaissance activities, server attack, etc.). When you select a group from a 
dropdown filter, only those rules and reports that are members are displayed on the page. When you 
select a rule group on the Incidents page, only those incidents related to the rules of the selected group 
display. Report and rule groups can also be used when constructing queries. 


For instance, there are at least 16 system rules that detect suspicious network access events and incidents, 
and 15 system reports to report this information. CS-MARS provides a system rule group and a system 
report group named “Access” that can filter the Inspection Rules, Incidents, and Report pages to display 
only those rules and reports related to monitoring access event (such as password attacks), thereby 
eliminating the need to search for the pertinent rules and reports within the complete rule and report 
pages or dropdown lists. CS-MARS provides system rule and report groups as listed in Table 21-2. 


Table 21-2 Predefined Rule and Report Groups 
System Report Groups Corresponding System Rule Groups 
System: Access System: Access 


System: All Events - Aggregate View — 


System: All Exploits - Aggregate View — 


System: COBIT DS3.3 - Monitoring and — 
Reporting 


System: COBIT DS5.10: Security Violations — 
System: COBIT DS5.19: Malicious software — 
System: COBIT DS5.20: Firewall control — 


System: COBIT DS5.2: Authentication and — 
Access 


System: COBIT DS5.4: User Account Changes |— 


System: COBIT DS5.7: Security Surveillance — 


System: COBIT DS9.4: Configuraton Control — 


System: COBIT DS9.5: Unauthorized Software |— 


System: CS-MARS Distributed Threat Mitigation |System: CS-MARS Distributed Threat Mitigation 
(Cisco DTM) (Cisco DTM) 


System: CS-MARS Incident Response System: CS-MARS Incident Response 


System: CS-MARS Issue 
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Table 21-2 


System Report Groups 


Predefined Rule and Report Groups (continued) 


Corresponding System Rule Groups 


System: Client Exploits, Virus, Worm and System: Client Exploits, Virus, Worm and 
Malware Malware 

System: Configuration Changes —_— 

System: Configuration Issue System: Configuration Issue 

System: Database Server Activity System: Database Server Activity 

System: Host Activity System: Host Activity 

System: Network Attacks and DoS System: Network Attacks and DoS 

System: New Malware Outbreak (Cisco ICS) System: New Malware Outbreak (Cisco ICS) 
System: Operational Issue System: Operational Issue 

System: Reconnaissance System: Reconnaissance 

System: Resource Issue System: Resource Issue 

System: Resource Usage — 

System: Restricted Network Traffic System: Restricted Network Traffic 

System: SOX 302(a)(4)(A) — 

System: SOX 302(a)(4)(D) — 

System: Security Posture Compliance (Cisco System: Security Posture Compliance (Cisco 
NAC) NAC) 

System: Server Exploits System: Server Exploits 


Global Controller and Local Controller Restrictions for Rule and Report Groups 


Global Controller and Local Controller rule and report groups have the following restrictions: 


e Rule and report groups created on the Global Controller are pushed to all the Local Controllers. 


e Rule groups created on a Local Controller are local to the Local Controller. They are not copied to 
the Global Controller or to other Local Controllers. 


e Local Controller account holders can edit only the Source IP, Destination IP, and Device fields of a 


rule group created on a Global Controller. 


¢ Local Controller account holders cannot edit Global Controller report groups. 


¢ Local Controller account holders cannot delete Global Controller rule and report groups. 


wy 


Note 


The procedures described in this section are valid for both the Local and Global Controllers, except that 


the Case Bar does not appear on the Global Controller HTML interface. 


Add, Modify, and Delete a Rule Group 


Adding a New Rule Group 


To add a rule group follow these steps: 
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Step 1 


Step 2 


Step 3 
Step 4 


Step 5 


Step 6 


Rule and Report Groups Wi 


Navigate to the Inspection Rules page, as shown in Figure 21-10. 


Figure 21-10 Inspection Rules Page 


Cisco Systems 


SUMMARY || INCIDENTS || QUERY / REPORTS [putes | MANAGEMENT || ADMIN || HELP 
Inspection Rules |[ Drop Rules 


Briss | CS-MARS Standalone: LG20-Doc v4.1 Login: Administrator (pmnadmin) i: | Logout | i} | Activate 


Select Case: [No Case Selecte 


Inspection Rules: 


Group: [Rule Groups | view: [active fe] [ edit Group Delete Group Add Group 


Edit Change Status Duplicate Add 
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Click Add Group. 
The Add Group dialog box appears, as shown in Figure 21-11. 


Figure 21-11 Add Group Dialog Box 


Rule Group 


Name: { 


Select All 


System Rule: Backdoor: Active 


I> 


System Rule: Backdoor: Connect — 


System Rule; Backdoor: Covert Channel 


System Rule: Backdoor: Spyware 

System Rule; CS-MARS Host Mitigation - Failure 

System Rule: CS-MARS Host Mitigation - Success 
System Rule; Client Exploit - Attempt 

System Rule: Client Exploit - Mass Mailing Worm 
System Rule; Client Exploit - Sasser Worm 


System Rule: Client Exploit - Success Likely 


25s nedlee mised Pucind | Guclsse races: | 


Biotodododoo 


> 
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Cancel Submit 


Enter the new group name in the Name field. 


Click the checkboxes of the rules to be added to the new rule group. 


Je) 


Tip The dropdown list above the list of rules can limit the display of rules to active system rules, 
active user rules, or inactive rules. The search function displays only those rules that match a 
search string (for example, “New Malware Traffic Match.”). The asterisk wildcard character (*) 
is supported. 


Click Add. 
The selected rules appear in the lefthand pane of the dialog box. To remove a rule from the group, 
highlight the item in the lefthand pane and click Remove. 


Click Submit. 

The new rule group name appears in the Group dropdown filter on the Inspection Rules page, as shown 
in Figure 21-12. In this example, the new rule group name is “Example Group.” Because it is a 
user-created rule group, the rule group name appears without the prefix “System.” You can also click 
Cancel to return to the Inspection Rules page without creating a new rule group. 
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Step 2 
Step 3 


Step 4 


Step 5 


Step 1 
Step 2 
Step 3 


Step 4 


Figure 21-12 New Rule Group Appears on the Dropdown List of the Inspections Rules Page 


Cisco SYSTEMS 


Inspection Rules 


PA RULES | CS-MARS Standalone: LC20-Doc v4.1 


Select Case: [No Case Selected... 


Inspection Rules: 


Group: [--Rule Groups-- | 


--Rule Groups-- 
Example Group 
s 2m Group: Access 
MARS Incident Response 
nt Exploits, Virus, Worm and Malware 
: Configuration Issue 
: Database Server Activity 
: Host Acti 
2m Group: Network Attacks and DoS 
2m Group: Operational Issue 
: Reconnaissance 
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Modifying a Rule Group 
To edit a rule group, follow these steps: 


Navigate to the Inspection Rules page, as shown in Figure 21-10. 
Select the rule group to edit in the Group pulldown filter. 


Click Edit Group. 
The Add Group dialog box appears, as shown in Figure 21-11. The rule group name appears in the Name 
field, and the included rules appear as selected rules in the lefthand pane of the dialog box. 


To add additional rules, click the checkbox of all the rules to be added to the group, then click Add. 
To remove rules, highlight the items in the lefthand pane to remove, then click Remove. 


Click Submit. 


Deleting a Rule Group 


Navigate to the Inspection Rules page, as shown in Figure 21-10. 
Select the rule group to delete in the Group pulldown filter. 


Click Delete Group. 
The Delete Group dialog box appears listing the rules in the group to be deleted. You are prompted to 
confirm deletion. 


Click Yes. 
The rule group no longer appears in the Group dropdown filters on the Incident and Inspection Rules 
pages. 
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Add, Modify, and Delete a Report Group 


Adding a New Report Group 
To add a report group follow these steps: 


Step1 Navigate to the Report page, as shown in Figure 21-13. 


Figure 21-13 Reports Page 


Cisco Systems 


SUMMARY || INCIDENTS [query / rerorts | RULES || MANAGEMENT || ADMIN || HELP 


[By auerr / neronrs | CS-MARS Standalone: LG20-Doc v4.1 Login: Administrator (pnadmin) ¢: | Logout | 41 | Activate 


Select Case: [No Case Selected. 


Report Selection 


Group: [all 5 Schedule: [All = Edit Group Delete Group Add Group br 
Edit Delete Add Resubmit View Report [view HTML Le] a 
Name Schedule |Format|Recipients|Query Description Status Submitted |Time Range st 
Step2 Click Add Group. 
The Add Group dialog box appears, as shown in Figure 21-14. 
Figure 21-14 Add Report Group Dialog Box 
Report Group 
Name: 
Select all 
[ [- Activity: all - NAT Connections (Total View) 4 
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[- Activity: all - Top Event Types (Peak View) 
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[- Activity: all - Top Reporting Devices (Total View) 
[O Activity: all - Top Sources (Peak View) 
[- Activity: All - Top Users (Recent View) 
[O Activity: all Events and Netflow - Top Destination Ports (Peak View) 
Riakiictiees AM Re mainme Tem Nackin ction Meube bis Misha a fake Mase’ bs 
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Cancel Submit |= 


Step3 Enter the new report group name in the Name field. 


Step4 = Click the checkboxes of the reports to be added to the new report group. 


Je) 


Tip The dropdown filter above the list of reports can filter the display of reports to display system 
reports, user reports, or all reports. The search function displays only those reports that match a 
search string (for example, “Spy” for Spyware). The asterisk wildcard character (*) is supported. 


Step5 Click Add. 
The selected reports appear in the lefthand pane of the dialog box. To remove a report from the group, 
highlight the item in the lefthand pane and click Remove. 
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Step 6 


Step 1 
Step 2 
Step 3 


Step 4 


Step 5 


Step 1 
Step 2 


Click Submit. 

The new report group name appears in the Group dropdown list display filter on the Report page, as 
shown in Figure 21-15, and on the Query Page. Because it is a user-created report group, the report group 
name appears without the prefix “system.” You can also click Cancel to return to the Report page 
without creating a new report group. 


Figure 21-15 The New Report Group Appears on the Dropdown Filter of the Report Page 


Cisco SYSTEMS 


Est QUERY / REPORTS | CS-MARS Standalone: LC20- 


Select Case: |No Case Selected... 


Report Selection 


Group: [--Report Groups-- ~] 
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Modifying a Report Group 


To edit a report group, follow these steps: 


Navigate to the Reports page, as shown in Figure 21-13. 
Select the report group to edit from the Group pull-down list. 


Click Edit Group. 

The Add Report Group dialog box appears, as shown in Figure 21-14. The report group name appears in 
the Name field, and the reports that comprise the report group appear in the lefthand pane of the dialog 
box. 


To add additional reports, click the checkboxes of the reports to be added to the group, then click Add. 
To remove reports, highlight the items to remove in the lefthand pane, then click Remove. 


Click Submit. 


Deleting a Report Group 


Navigate to the Reports page, as shown in Figure 21-13. 
Select the report group to delete in the Group pulldown filter. 
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Step3 Click Delete Group. 
The Delete Report Group dialog box appears listing the reports in the group to delete. You are prompted 
to verify deletion. 
Step4 = Click Yes. 


The report group no longer appears in the report group dropdown lists on the Report and Query pages. 


Display Incidents Related to a Rule Group 


Step 1 
Step 2 


To display incidents that occur from the firing of rules in a specific rule group, follow these steps: 


Navigate to the Incidents page. 


Select the rule group in the dropdown filter above the Matched Rules column, as shown in Figure 21-16. 
The Incidents page will display only those incidents that occurred from rules firing in the selected rule 


group. 


Figure 21-16 Rule Group on Incidents Page 
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Create Query Criteria with Report Groups 


To create queries from report groups, follow these steps: 


Step1 Navigate to the Query page. 


Step2 Select areport group in the Load Report as On-Demand Query with Filter dropdown filter, as shown 


in Figure 21-17. 


Only the reports that comprise the report group can now display in the Select Report dropdown list, as 


shown in Figure 21-18. 


Figure 21-17 Selecting A Report Group to Make a Query 
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Figure 21-18 Selecting a Report Within the Report Group to Make a Query 
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Step3 Select the report in the secondary dropdown list. 
The Query criteria are automatically populated per the selected report. 
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Using Rule Groups in Query Criteria 


Step 1 
Step 2 


Step 3 


Step 4 
Step 5 


Step 6 


To populate the Rule field of the Query Event Data bar using rule groups, follow these steps: 


Navigate to the Query page. 


Click Any in the Rules field of the Query Event Data bar. 
The Filter by Rule dialog box appears as shown in Figure 21-19. 


Select the rule group in the dropdown list above the list of rules, as shown in Figure 21-14. 
The list of rules will display only those rules in the selected rule group. 


Figure 21-19 Rule Group Used to Populate Rule Criterion in Query 
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Click the checkboxes of the rules to include in the query. 


Click Add. The selected items appear in the lefthand pane of the Query dialog box. 

To remove rules, highlight the items to remove in the lefthand pane, then click Remove. 
Click Apply. 

The selected rules appear in the Rules field of the Query Event Data bar. 
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Sending Alerts and Incident Notifications 


A Cisco Systems MARS alert action is a signal transmitted to people or devices as notification that a 
MARS rule has fired, and that an incident has been logged. Alert actions can only be configured through 
the Action parameter of a rule. An alert action determines which alert notification types are sent to which 
MARS user accounts or user groups. MARS can transmit alerts by the methods listed in Table 22-1. 
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Table 22-1 MARS Incident Notification Methods 


Alert Notification Type Description 


Sent in Human-Readable Format 


e E-mail E-mail, SMS, and pager alerts send the incident 
© XML Notification ID, matched rule name, severity, and incident time 
in email, SMS and pager formats respectively. 

e Short Message Service (SMS) You must login to the MARS to view all the 


e Pager incident details. 


XML notification sends an email notification of 
an incident with an attached XML data file (see 
Example 22-2). The XML data file contains the 
same incident details that can be viewed from the 
GUI, except for path and mitigation information. 
The XML data file can be sent as a plain-text file 
or as acompressed gzip file. The XML data 
filename is constructed with the incident ID 
number, for example 
CS-MARS-Incident-13725095.xml. You can parse 
and extract data from the XML file with a custom 
application. For example, you can integrate the 
XML data with trouble ticketing software. See 
Appendix A, “Cisco Security MARS XML API 
Reference,” for further information on the MARS 
XML notification schema and usage guidelines. 


MARS SMS text message notifications can be up 
to 160 characters in length. Because the MARS 
SMS incident notification exceeds 160 characters, 
it is sent in three segments. 


Pager messages are sent through the MARS 
internal modem. MARS dials a carrier’s IXO/TAP 
number and uses SNPP to transmit the 
alpha-numeric page. Pager notifications are still 
possible when the network is down. Pagers can 
often receive messages in places where mobile 
phones are inoperative or forbidden (for instance, 
hospitals). 


Sent to a Device 


e SNMP trap These alerts send the incident ID, matched rule 
severity, and incident time to devices or 
applications, all of which must be properly 

¢ Distributed Threat Mitigation configured within the MARS device 
administration pages. See the section, Reporting 
and Mitigation Devices Overview, page 2-1 for 
information on configuring individual devices to 
work with MARS. 


e Syslog 
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Table 22-2 provides links and description of related Alert Action configuration procedures. Although 
some of these procedures are documented elsewhere in this user guide, they are duplicated here for your 


convenience. 

Table 22-2 Alert Notification Procedures 

Alert Related Procedures Description 

Configure the E-mail Server Settings To send Email, SMS, and XML notifications, 
MARS requires that you configure the E-mail 
Server settings. 

Configure a Rule to Send an Alert Action Complete this procedure to create or modify an 
alert action. 

Create a New User—Role, Identity, Password, Alert notifications can be sent only to user 

and Notification Information accounts configured on MARS. A new user 


account can be configured from the User 
Management tab, or when creating an alert action 
for a rule. This is where you enter the service 
provider phone numbers and email addresses for 
E-mail, SMS, Pager, and 


Create a Custom User Group Complete this procedure to create a MARS user 

group other than the default MARS user groups. 

Unlike default user groups, custom groups can be 
edited. 


Add a User to a Custom User Group Complete this procedure to include a newly 
created user account into a MARS user group. 


Example 22-1 shows a typical email alert notification. Example 22-2 shows an XML notification with 
its attached XML data file. When compression is configured, the XML date file arrives as a GZIP 
compressed file. 


Note Alert notifications cannot be customized. 


Example 22-1 MARS Notification by Email 


From: notifier.Latest@serviceprovider.cisco.com [mailto:notifier.MyLatest@cisco.com] 
Sent: Monday, May 15, 2006 8:48 AM 

To: Naliza Mahda (Nalmah) 

Subject: Incident Notification (green, Rule Name: System Rule: CS-MARS Database Partition 
Usage) 


The following incident occurred: 


Start time: Mon May 15 08:47:26 2006 

End time: Mon May 15 08:47:26 2006 

Fired Rule Id: 134473 

Fired Rule: System Rule: CS-MARS Database Partition Usage 
Incident Id: 597842933 


For more details about this incident, please go to: 


https: //MyLatest/Incidents/IncidentDetails.jsp?Incident Id=597842933 
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https: //MyLatest.cisco.com/Incidents/IncidentDetails.jsp?Incident Td=597842933 
https://10.2.3.7/Incidents/IncidentDetails.jsp?Incident Id=597842933 
https://192.168.1.101/Incidents/IncidentDetails.jsp?Incident Id=597842933 


For all recent incidents, please go to: 


https: //MyLatest/Incidents/ 

https: //MyLatest.cisco.com/Incidents 
https: //10.2.3.7/Incidents 

https: //192 .162 .1.101/Incidents 


Example 22-2. MARS XML Notification Email Attachment 


4 xml notification example - Message (HTML) 
i File Edit Yiew Insert Format Tools Actions Help 
i QuReply ejiReply to all | (2 Forward =| E a] = Late |S) R54 XK | es es AF | © 


From: cs-mars (indra)[indra @cisco.com] Sent: Wed 6/14/2006 5:08 PM 
To: Lorn Ness (Iness) 

€c} 

Subject: CS-MARS Incident: 385975495 (Source AND Dest rule test) 


Attachments: (] CS5-MARS-Incident-385975495.xml (1 KB) 


Details for the CS-MARS Incident: 385975495 is attached. 


190155 


Configure the E-mail Server Settings 


To send alert actions, MARS must be configured to communicate with an e-mail server. To configure the 
e-mail server settings, follow these steps: 


Step1 Click Admin > Configuration Information. 


The Device Configuration window appears, as shown in Figure 22-1. 
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Figure 22-1 MARS Device Configuration Window 
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> Mail Gateway: 


IP:Port [64.101.176.33 }25__ | 


Email domain name: [-j 


(ex: Enter 'domain1' for user@domain1) 
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Step2 = In the IP:Port field of the Mail Gateway section, enter the IP address and Email Domain Name of your 
Mail Gateway server. 


Step3 = Click the Update button at the bottom of the page to update the MARS configuration. 


Configure a Rule to Send an Alert Action 


To send alert notifications to individual users or groups of users, configure the Action parameters of a 
rule to create an alert action. This procedure configures alerts for pre-existing rules. When you create a 
rule, the Action parameters are configured after the count number parameter. 


\ 


Note Drop rules do not have Action parameters and cannot trigger alerts. 


To modify or create an alert for an existing rule, follow these steps: 


Step 1 Click the RULES tab to navigate to the Inspection Rules page. 
Step2 Identify the Rule to configure, and click the value displayed in the Action field. 


The Action Selection dialog box, as shown in Figure 22-2, appears below the rule description table. All 
previously defined alert actions are listed in the right-hand area of the Action dialog box. An alert action 
determines which alert notifications are sent to which users or user groups when the rule fires. You can 
edit or delete existing alert actions or create a new one. 
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Figure 22-2 Action Selection Dialog 
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| Apply | | Previous Next 


Step3. Do one of the following five actions: 
1. Remove an alert action currently applied to the rule. 


- In the left-hand area, pick the alert actions to remove with Ctrl+Click, then click Remove >>. 
The alert action is deleted from the left-hand area. 
- Proceed to Step 13 to complete the procedure. 


e Apply an existing alert action to the rule. 


- Inthe right-hand area, click the check boxes of the alert actions you require, then click <<==. 
The alert action appears in the left-hand area. 

- Proceed to Step 13 to complete the procedure. 

e Delete an existing alert action from MARS. 

- Click the check box of the alert action in the right-hand area, then click Delete. 
A delete verification window appears. 

- Click Yes. 
The alert action is deleted from the right-hand area. 

- Proceed to Step 13 to complete the procedure. 


e Edit an existing alert action. 


- Click the check box of the alert action in the right-hand area, then click Edit. 
The Alert recipients page appears in a new window, as shown in Figure 22-3. 
- Proceed to Step 4 to complete the procedure. 
e Create a new alert action. 


- Click Add. 


The Alert recipients page appears in an a new window, as shown in Figure 22-3. 
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Configure a Rule to Send an Alert Action Hi 
- Proceed to Step 4 to complete the procedure. 
Figure 22-3 Alert Recipients Window 
Name: Alert for 
Description: Sass 
fr Email Change Recipient [- Syslog Change Recipient 
f- Page Change Recipient [~ SNMP Change Recipient 
jy SMS Change Recipient [Distributed Threat Mitigation Change Recipient 
— Alarm f Drop pf Reset 
fr Deny Attacker ~~ Deny Flow 
Lucre, Phremeus 
jv XML Email Change Recipient 
f— Compress 
Lucre, Phremeus 
=] 
is) 
Cancel Submit 5 
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Step 4 


Step 5 


Recipients for the notification types are as follows: 


e E-mail—uUsers or user groups can receive an e-mail. 


Click the check box of a notification type to select or deselect it. 


e Page—Users or user groups can receive an alpha-numeric electronic page on their pagers or 


pager-enabled mobile telephones. 


e SMS—tUsers or groups can receive a text message on their SMS-enabled mobile telephones. 


| 78-17020-01 


For a new alert enter a name and description in the Name and Description fields. If editing an existing 
alert, you can modify the name or description. 
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e XML Email—Users or groups can receive an email message with incident details appended in an 
XML data file. Click the Compress check box to send the XML data file as a compressed gzip file. 
For more information on this feature, see Appendix A, “Cisco Security MARS XML API 
Reference.” 


e Syslog—Specified devices can receive syslog messages. 
e SNMP—Specified devices can receive SNMP trap information. 


e Distributed Threat Mitigation—For more information on this feature, see Technology Preview: 
Configuring Distributed Threat Mitigation with Intrusion Prevention System in Cisco Security 
MARS, page 1. 


Note For SNMP and Syslog, you must configure the receiving systems to receive notifications. 


Step6 Click the Change Recipient button to add or remove a recipient for a notification type. 


For E-Mail, Page, SMS, and XML Email, the Select (recipient) dialog box appears, as shown in 
Figure 22-4. 


Figure 22-4 Select Recipient Dialog Box 


Select 


Select all All Users ¥) 


Lucre, Phremeus (slimy) = Administrator (pnadmin) i 


s (pnadmin2) 


= cre, Phremeus 


rt Test, GC (gcTest) 


|< 


Add || Edit Delete 


Cancel Submit 


143782 
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For Syslog and SNMP, the Select (device) dialog box appears, as shown in Figure 22-5. 


Figure 22-5 Device Selection Page 


Select 


Select All 


vy [10.10.10.11] mcafee: etherO 


r~ [10.10.10.13] ISS: etherO 


r~ [10.89.149.151] LC20-Doc: etho 


r~ [192.168.1.100] LC20-Doe: eth1 


yy [192.168.6.123] Check Point Example 


p~ [192.168.7.123] Check Point Example 


|| 


Cancel Submit 


143793 


For Distributed Threat Management notification, the Select (IOS-IPS Devices) dialog appears (not 
shown). 


Tip If you do not know the group to which a user or device belongs, select All from the dropdown list to view 
all users or devices. 


Step7 Click the check box next to the users or device you want to receive the notification, then click << Add. 


Your selections appear in the left-hand area. To remove items, Ctrl+click the items in the left-hand area, 
then click Remove. The items are then deleted from the left-hand area. 


Step8 If you are not adding a user, skip to Step 9. To add a new user, do the following substeps: 
a. Click Add. 
The User Configuration page appears in a separate window, as shown in Figure 22-6. 
b. Enter the User Configuration information then click Submit. 
You are returned to the Select Recipient Dialog Box. 


For reference on user configuration fields, see the section, “Create a New User—Role, Identity, 
Password, and Notification Information” 


c. Add the new user to the recipient list as described in Step 7. 
Step9 Click Submit. 
You are returned to the Alert Recipients Window. 


Step10 Repeat Step 6 through Step 9 until you have assigned recipients to all the notification types you have 
selected. 


Step11. Click Submit. 
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Step 12 


Step 13 


Step 14 


Step 15 
Step 16 


You are returned to the Action Selection Dialog. Any newly-created or edited action alert appears in the 
right-hand area. 


Click the check boxes next to the action alerts to be sent when the rule fires. Click << Add. 
Your selections appear in the left-hand area. 

Click Next. 

The Time Range dialog may or may not appear. 

Click Next if the Time Range dialog appears. 

The Rule Summary table appears. 

Click Submit to save your changes to the rule. 

Verify that the alert actions you selected appear in the Action field of the rule description. 
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Note An inactive rule is made active by applying an alert action. To inactivate a rule, select the rule 
and click Change Status. 


This ends the Configure a Rule to Send an Alert Action procedure. 


Create a New User—Role, Identity, Password, and Notification 
Information 


Step 1 


To create a new MARS user, complete the following steps: 


New user accounts and user groups are created on the Management > User Management tab, or as a 
substep in creating an alert notification recipient (with the Add button on the Select [user] dialog). 


Navigate to the User Management page by either of the following methods: 
e Click Add on the Management > User Management tab. 


e¢ Click Add on the Select (user) dialog box when creating an alert notification. See “Configure a Rule 
to Send an Alert Action” section on page 22-5. 


The User Configuration page appears, as shown in Figure 22-6. 
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Step 2 


Step 3 
Step 4 


Step 5 
Step 6 


Figure 22-6 


Create a New User—Role, Identity, Password, and Notification Information Ml 


User Configuration Page 


Role: Admin 


Login: pnadmin 


Password: [secceeeee 


Re-enter password: 


First Name: [administrator 


Last Name: [administrator 


Organization: |cisco Systems, Inc. 


Email: 


SMS: 


Work Phone: /ggg-555-1212 


Home Phone: [885552121 


Fax: 


Pager: { Cell phone or pager number e.g: 4082345678 ) 


Service Provider: | TestPage v Edit Provider 


Cancel 


cap) 

ld 

- co 
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From the Role field, select a Role for the user. 


Admin: has full use of the MARS. 


Notification Only: for a non-user of the MARS appliance, use this to send alerts to people who are 
not administrators, security analysts, or operators. 


Operator: has read-only privileges. 


Security Analyst: has full use of the MARS, except cannot access the Admin tab 


Create or change the user’s password if necessary. 


Enter the user’s credentials and personal information, which may include any of the following: 


First name 

Last name 

Organization name 

Email address 

Short Message Service (SMS) number—for example, 8885551212 @servprov.com 
Work telephone number 

Home telephone number 

FAX number 


Pager number or ID— may also be a mobile telephone number, for example, 5552345678 


If you are not creating a notification by pager, go to Step 10. 


For notification by pager, you must specify a service provider (cell phone or pager company). From the 
Service Provider field, select New Provider. 
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This pull-down menu is populated as you add new providers. 


Additional service provider information fields appear on the same page, as shown in Figure 22-7. 


Figure 22-7 Service Provider Fields to Add or Change a Service Provider 


Provider Name: 


Provider Phone No: [9,18002345678 ]< e.g: 9,18002345678 ) 


Provider Baudrate: [400 —~—<C:i‘CSCizd' 


143372 


Step 7 In the Provider Name field, enter the name of the service provider. 
Step8 In the Provider Phone No field, enter the service provider’s telephone number. 


This is the number the service provider requires for accepting alpha-numeric messages using the 
IXO/TAP protocol. The format is like a regular phone number, such as: 18001234567. The format of 
1-800-1234567 is also acceptable. If dialing “9” is required to access a number outside your private 
branch exchange, type a “9,” before the full telephone number (for example, 9,1-800-1234567). 


Step9 In the Provider Baudrate field, enter the baud rate specified by the provider. 


This is the baud rate the service provider requires for the specified phone number. Common values are 
1200, 2400, 4800, and 9600. 


Step10 Click Submit to close the User Configuration page and return to the User Management tab. 


This ends the Create a New User—Role, Identity, Password, and Notification Information procedure. 


Create a Custom User Group 


To create a custom user group in addition to the default groups created by MARS, complete the following 
procedure: 


Step 1 Navigate to the Management > User Management tab. 

Step2 Click Add Group. 

Step3 In the Name field, enter a name for the group. 

Step4 To add users to the group, click the check box of users from the list on the right-hand area. Click Add. 
The checked names appear in the left-hand side of the dialog box. 
To remove users from the group, pick the users from the left-hand side with Ctrl+click. Click Remove. 
The selected names appear in the right-hand side of the dialog box. 

Step5 Click Submit. 
You are returned to the User Management tab. 


This ends the Create a Custom User Group procedure. 


User Guide for Cisco Security MARS Local Controller 
P2212 78-17020-01 | 


| Chapter 22 


Sending Alerts and Incident Notifications 


Adda Usertoa Custom UserGroup Hl 


Add a User to a Custom User Group 
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To include a user in a custom User Group, complete the following steps: 


Note 


Step 1 
Step 2 


Step 3 
Step 4 


Step 5 


The user is automatically added to the User Group that corresponds to their role. Admin, Operator, 
Notification, and Security Analyst are system groups and cannot be edited. 


Navigate to the Management > User Management tab. 

Select the User Group to edit from the Select Group dropdown list. 
The members of the group are displayed. 

Click Edit Group. The User Group dialog box appears. 


Check the users to add to the group from the list on the right hand side. Click Add. The checked names 
move to the left-hand area of the dialog box. 


Click Submit. 
You are returned to the User Management tab. 


This ends the Add a User to a Custom User Group procedure. 


| 78-17020-01 


User Guide for Cisco Security MARS Local Controller | 


Chapter 22 — Sending Alerts and Incident Notifications | 


HI Add a User to a Custom User Group 


User Guide for Cisco Security MARS Local Controller 
P2214 78-17020-01 | 


ey a 


Management Tab Overview 


Use the management features in the Local Controller to assign: event, addressing, service, and user 
information. This information is used in rules, queries, and to determine false positives. 


Activating 


In general, you need to activate changes in the Management tabs if the changes are part of a rule. 


To activate a set of management additions or changes 


Step 1 When changes (or additions) are complete, activate them by clicking Activate. 


Figure 23-1 Clicking the Activate Button 


GEMENT || ADMIN || HELP 


11 PM PDT :: 


143359 


Event Management 


To open the Event Management sub-tab, click the Management > Event Management tabs. 


On the Event Management page, you can search and filter events and event groups, and work with groups 
of events. 


Search for an Event Description or CVE Names 


You can search for partial matches of event descriptions or Common Vulnerabilities and Exposures 
(CVE) names. 
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Event Groups 


Step 1 Enter the text that you want to search for in the Search field. 
Step2 Click Search. 


To view a list of all currently supported CVEs 


Step 1 Enter CVE into the Search field. 
Step2 Click Search. 


Event Groups 


Using and creating event groups is one of the most powerful ways to leverage rules. You can take any of 
the events presented here, group them, and then use them with rules to concentrate your searches for 
attacks. 


To filter by event groups or severity 


From the appropriate list, select the group or severity. 


Edit a Group of Events 
& 


Note You can not edit system-defined groups. 


Step 1 Select the group in the Select Group list. 

Step2 Click Edit Group. 

Step3 = Click each group in the Chosen and Available fields to highlight it. Click it again to de-highlight it. 
Step4 Click Add or Remove to move highlighted items as needed. 

Step5 Click Submit. 


Add a Group 


Step 1 Click Add. 
Step2 In the Name field, enter a name for the group. 


Step3 —_—In the Available field, click each group that you want to add to highlight it. Click it again to de-highlight 
it. 
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Step 5 


IP Management Wl 


Click Add. 
Click Submit. 


IP Management 


The IP Management page, accessed by clicking Management > IP Management, enables the definition 
of network assets that you use as building blocks for inspection rules, drop rules, reports and queries, 
topology discovery schedules, and in defining reporting devices and mitigation devices. You can define 
assets as networks, IP ranges, or hosts. You can also defined named variables for use within inspection 
rules. 


The vulnerability assessment information that you define for a host, specifically the operating system 
type and patch level and the known services that run on the host, assists MARS in determining false 
positives. 


Tip 


You can filter the list of objects displayed by the View list box. This selection allows you to filter to 
hosts, networks, IP ranges, or variables. 


Search for an Address, Network, Variable, or Host 


Step 1 
Step 2 


Enter the text that you want to search for in the Search field. 
Click Search. 


Filter by Groups 


Edit a Group 


Step 1 


Step 2 
Step 3 
Step 4 
Step 5 
Step 6 


From the Select Group list, select the group. 


Select Management > IP Management. 

The IP Management page appears. 

Select the group in the Select Group list. 

Click Edit Group. 

Click each group in the Chosen and Available fields to highlight it. Click it again to de-highlight it. 
Click Add or Remove to move highlighted items as needed. 

Click Submit. 
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Add a Group 


Step 1 Select Management > IP Management. 
The IP Management page appears. 
Step2 Click Add Group. 
Step3 = In the Name field, enter a name for the group. 
Step4 _—_In the Available field, click a group to highlight it. To de-highlight an item, click it again. 
Step5 Click Add to move the selected Event Type Groups into the Chosen field. 
Step6 Click Submit. 


Add a Network, IP Range, or Variable 


Step 1 Select Management > IP Management. 


The IP Management page appears. 


Figure 23-2 Add a Network, IP Range, or Variable 
Type: | Network z] 


IP Range 
Variables 1 


| 


eC IL JL IL 4] 


Mask: 
w 
e 
oO 
be 


Step2 Click Add. 
Step3 = In the Type list select: network, IP range, or variable. 
Step4 For each type enter the appropriate information. 

e Network: name, network IP, network mask 

e IP range: name and range 

e Variable: variable name 


Step5 Click Submit. 


Add a Host 


Within MARS, a host is manually or automatically defined as the result of one of the following options: 
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A reporting device or mitigation device defined under the Admin > Security and Monitoring Devices 
tab. 


A host managed by a reporting device defined under the Admin > Security and Monitoring Devices 
tab, such as a host running Cisco Security Agent and discovered by MARS when processing the logs 
provided by the CSA Management Console. 


An asset that you want to identify for the purpose of actively interacting with that host from the 
MARS system, such as third-party syslog sever to which you want to forward syslog messages using 
alerts. 


A host that is discovered by the system as part of topology discovery. For example, when processing 


the ARP cache table on a Cisco Catalyst Switch. 


e A host involved in a session that, at one time or another, was considered suspicious, such as a 


potential target of an attack. In this case, MARS will have performed a Nessus and nmap port sweep 


of the host to identify whether it was likely breached. 


Because of these various options, you can have a large number of hosts defined on the IP Management 
page in the web interface. If you do not have a vulnerability assessment package that is compatible with 


MARS, you should consider providing as much information as possible about these hosts. For more 
information, see Define Vulnerability Assessment Information, page 10-11. 


Note 


Step 1 


Step 2 
Step 3 


If you are attempting to add a host and you are detecting a conflict with a previously defined host, 
seeDelete a Device, page 2-19 for additional troubleshooting information. 


To manually add a host, follow these steps: 


Select Management > IP Management. 
The IP Management page appears. 

Click Add. 

In the Type list select host. 
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Step 4 
Step 5 


Step 6 


Step 7 


Step 8 
Step 9 


Step 10 
Step 11 


Figure 23-3 General Information for a Host 
Type: [Host =] 
g 
General ¥ulnerability Assessment Info 


> *Device Name: | 
> Access IP: a | | 


> Operating System: |i" 
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> Nets1os Name: [J 


Enter interface information: 
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Name: IP Address: Network Mask: 
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In the Name field, enter the host’s name. 


In the Access IP field, identify the address used to pull log events from this host or used to connect to 
when performing dynamic vulnerability assessments while investigating detected attacks. 


If the host is running a variety of Windows, Solaris, or Linux, select the corresponding value in the 
Operating System field. Otherwise, verify that Generic is selected. 


If your are running NetBIOS on your network, enter the name associated with this host. 


NetBIOS provides name registration and resolution services. MARS uses this setting to provide attack 
path analysis and address resolution. 


Add as many IP address and masks to the interface by clicking Add IP/Mask. 


Under Enter Interface Information, enter the values for the interface name, IP address, and network 
mask. 


If you have a dual-homed host, you can add additional interfaces by clicking Add Interface. 


To specify vulnerability assessment information, continue with Define Vulnerability Assessment 
Information, page 10-11. 


Edit Host Information 


Step 1 
Step 2 
Step 3 


Select Management > IP Management. 
Check the box next to the host that you want to edit. 


If you are editing interface or IP mask information, make your changes here and click Submit. 
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Step4 —_If you need to edit the host’s properties, click Properties. 
Step5 Make changes to the operating system as necessary, and click Next. 


Step6 To make changes to service or application, remove the old service by select its radio button, and click 
Delete. 


Step7 Click Add Service, and continue with Step 3. 


Service Management 


To open the Service Management sub-tab, click the Management > Service Management tabs. 


Service is a combination of source port, destination port and protocol. The Service Management page 
displays services and their descriptions, ports and protocols. On the Service Management page, you can 
work with the services on your networks. 


Search for a Service 


Step 1 Enter the text that you want to search for in the Search field. 
Step2 Click Search. 
To filter by service groups 


From the appropriate list, select the group. 


Add a Group of Services 


Step 1 Click Add. 

Step2 In the Name field, enter a name for the group. 

Step 3 In the Available field, click items to select them, and click them again to de-select them. 
Step4 Click Add. 

Step5 Click Submit. 


Edit a Group of Services 
\, 


Note You can not edit system-defined groups. 


Step 1 Select the group in the Select Group list. 
Step2 Click Edit Group. 
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Step3 = Click each group in the Chosen and Available fields to highlight it. Click it again to de-highlight it. 


Step4 Click Add or Remove to move the highlighted items as needed. 


Step5 Click Submit. 


Add a Service 


Step 1 Click Add. 
Step2 Enter the service’s details. 


Step3 Click Submit. 


Edit a Service 


Step 1 Check the box next to the service. 
Step2 Click Edit. 
Step3. Make your changes, and click Submit. 


Delete a Service 


Step 1 Check the box next to the service. 
Step2 Click Delete. 


Step3 On the confirmation page, click Yes. 


User Management 


The User Management page allows you to manage users and administrators of the MARS system, 
including the roles and groups to which those users belong. On this page, you can define new user 
accounts, enabling access to specific features of the web interface. You can define user-specific 
notification settings for the user, such as a valid e-mail address or pager number. Some system-wide 
settings, such as pager and cell phone service provider settings, are also accessible exclusively through 
this page. To access the User Management page, click either Management > User Management or 


Admin > User Management. 


In MARS, four separate user roles exist that can be assigned to any user who needs to access the web 


interface: 


e Admin has full read/write privileges. Users in this role can define new users with any desired role. 
Users in the role can change the password settings of the accounts in any user role. 
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Step 1 


User Management Hl 


Security Analyst has full read privileges but is restricted to write for reports privileges. Users in this 
role can only define new users (and change passwords of users) with the Notifications Only role. 


Operator has read only privileges. Users in this role cannot define new users or change passwords, 
even of their own user account. 


Notifications Only. This user role has no permissions to access to the MARS web interface; use this 
role to identify users who will receive notifications, such as e-mail, SMS, or pager notifications. 


While roles are system defined, you can define, edit, and delete user groups. For more information, see 
Create a User Group, page 23-12 and Add or Remove a User from a User Group, page 23-12. 


Good security practices suggest strong passwords for use with the MARS Appliances. When defining 
user names and password, keep the following guidelines in mind: 


Login names and passwords: 


can be alphanumeric characters 
can contain special characters (!, @, #, etc.) 
cannot contain single or double quotes (‘or “) 


are case sensitive 


Login names can have up to 20 characters. Passwords can have up to 64 characters. 


Defining a new user involves specifying the user name, password, role, contact information, and 
notification information. 


To add a new user, follow these steps: 


From the Management > User Management tab, click Add. The User Configuration page appears, as 
shown in Figure 23-4. 
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Figure 23-4 User Configuration Page 


Role: Admin 


Login: pnadmin 


Password: [eeceecceee 


Re-enter password: 


First Name: [administrator 


Last Name: |administrator 


Organization: {cisco Systems, Inc. 


Email: [admin@ec 


SMS: fj 


Work Phone: [¢ 


Home Phone: |; 


Fax: 
Pager: [¢ ( Cell phone or pager number e.g: 4082345678 ) 
Service Provider: | Testpage v Edit Provider 


Dn 
i 
ise] 
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Step 2 From the Role field, select a Role for the user. 
e Admin: has full use of Local Controller. 


¢ Notification Only: for a non-user of the Local Controller appliance, use this to send alerts to people 
who are not admins, security analysts, or operators. 


e Operator: has read-only privileges. 
e Security Analyst: has full use of Local Controller, except cannot access the Admin tab 
Step3 Create or change the user’s password if necessary. 


Step4 Enter the user’s credentials and personal information. 
The information can include the following: 


e First name 

e Last name 

e Organization name 

e Email address 

e Short Message Service (SMS) number—for example, 8885551212 @servprov.com 
e Work telephone number 

e Home telephone number 

e FAX number 


e Pager number— may also be a mobile telephone number, for example, 5552345678 
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User Management 


If you are creating a notification by pager, go to the next section, “Add a Service Provider (Cell 


phone/Pager)”, otherwise click Submit to complete the procedure for adding a user. 


Add a Service Provider (Cell phone/Pager) 


Step 1 


Step 2 
Step 3 


Step 4 


Step 5 


When configuring a notification by pager, add a service provider (cell phone or pager company) by 


completing the following procedure: 


From the Service Provider field, select New Provider. Additional fields appear, as shown in 


Figure 23-5. 


The pull-down menu is populated as you add new service providers. 


Figure 23-5 Select a New Provider and Provide Contact Details 


Provider Name: [TestPage 


Provider Phone No; |9,18002345678 ] (e.g: 9,18002345678 ) 


Provider Baudrate: [o4no 


In the Provider Name field, enter the name of the service provider. 


In the Provider Phone No field, enter the service provider’s telephone number. 


143372 


This is the number the service provider uses for accepting alpha-numeric messages using the IXO/TAP 
protocol. The format is like a regular phone number, such as: 18001234567. The format of 


1-800-1234567 is also acceptable. If dialing “9” is required to access a number outside your private 


branch exchange, type a “9,” before the full telephone number (for example, 9,1-800-1234567). 


In the Provider Baudrate field, enter the baud rate specified by the provider. 


This is the baud rate the service provider requires for the specified phone number. Common values are 


1200, 2400, 4800, and 9600. 


Consult your service provider’s website for more information on their baud rates. 


Click Submit to close the User Configuration page and return to the User Management tab. 


Search for a User 


Step 1 
Step 2 


Enter the text that you want to search for in the Search field. 
Click Search. 
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Edit or Remove a User 


Step 1 
Step 2 
Step 3 


Step 4 
Step 5 


Form the Management User tab, check the box next to the user’s name. 
Click Delete to delete the user. 


Click Edit to change the user’s configuration information. 
The User Configuration page appears. 


Edit the User Configuration page. 
Click Submit. 


Create a User Group 


Step 1 
Step 2 
Step 3 


Step 4 


Step 5 


Click Add Group. 
In the Name field, enter a name for the group. 


To add to the group, check the users from the list on the right hand side. Click Add. 
The checked names move to the lefthand side of the dialog box. 


To remove users from the group, select the users from the left hand side with Ctrl+click . Click Remove. 
The selected names move to the righthand side of the dialog box. 


Click Submit. 


Add or Remove a User from a User Group 
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To add or remove a user from a custom User Group, do the following steps: 


Note 


Step 1 
Step 2 
Step 3 


Step 4 


Step 5 


Admin, Operator, Notification, and Security Analyst are system groups and cannot be edited. The user 
is automatically added to the User Group that corresponds to their role. 


Select the User Group from the Select Group field. The members of the group are displayed. 
Click Edit Group. The User Group dialog box appears. 


To add to the group, check the users from the list on the right hand side. Click Add. 
The checked names move to the lefthand side of the dialog box. 


To remove users from the group, select the users from the left hand side with Ctrl+click . Click Remove. 
The selected names move to the righthand side of the dialog box. 


Click Submit. You are returned to the User Management tab. 
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Filter by Groups 


From the Select Group list, select the group. Only the members of the group are displayed. 


User Guide for Cisco Security MARS Local Controller 
| 78-17020-01 23-13 | 


Chapter 23 | Management Tab Overview | 


HZ User Management 


User Guide for Cisco Security MARS Local Controller 
P2314 78-17020-01 | 


CHAPTER 


System Maintenance 


Much of the system maintenance information for the MARS Appliance is provided exclusively in the 
Install and Setup Guide for Cisco Security Monitoring, Analysis, and Response System. 


The MARS Appliance requires little maintenance. To perform maintenance tasks, you can use the CLI 
or the web interface as needed. Some hardware maintenance tasks require physical access to the MARS 
Appliance. 


This chapter contains the following sections: 
e Setting Runtime Logging Levels, page 24-1 
e Viewing the Appliance’s Log Files, page 24-2 
e Viewing the Audit Trail, page 24-3 
e Retrieving Raw Messages, page 24-3 
e Hard Drives, page 24-7 
e Replacing the Lithium Cell CMOS Battery, page 24-8 
e Change the Default Password of the Administrator Account, page 24-8 


For information about upgrading, backing up, and restoring data on the MARS Appliance, see the 
following sections of the Install and Setup Guide for Cisco Security Monitoring, Analysis, and Response 
System: 


e Performing Command Line Administration Tasks, page 6-1 

e Checklist for Upgrading the Appliance Software, page 6-7 

e Configuring and Performing Appliance Data Backups, page 6-18 
e Recovery Management, page 6-27 


Setting Runtime Logging Levels 


To set the appliance’s runtime logging levels, navigate to Admin > System Maintenance > Set Runtime 
Logging Levels. For typical use, it is best to leave this page set to its defaults. 


When you have made your selections, click the Change Logging Levels button. 
The following log levels are available: 


e Fatal. Enables fatal logging messages. Fatal messages record very severe error events that will likely 
lead the application to abort. 
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e Error. Enables error and fatal logging messages. Error messages record error events that might still 
allow the application to continue running. 


e Warn. Enables warning, error, and fatal logging messages. Warning messages record potentially 
harmful situations. 


e Info. Enables informational, warning, error, and fatal logging messages. Informational messages 
highlight the progress of the application at coarse-grained level. 


¢ Debug. Enables debug, informational, warning, error, and fatal logging messages. Debug messages 
record fine-grained informational events that are most useful to debug an application. 


e Trace. Enables trace, debug, information, warning, error, and fatal logging messages. Trace 
messages record finer-grained informational events than debug messages. 


Viewing the Appliance’s Log Files 


To view the appliance’s log files or to change their levels or source, navigate to Admin > System 
Maintenance > View Log Files. 


Figure 24-1 Back-end log viewing options 


Yiew Backend Log 


@ Last:]0 


Select Level: | All *] Select Source: | Backend =] 


14__{Hrs|4 Mins 


143387 


15 Hrs |4 Mins 


You can view the appliance’s back-end logs either by selecting a number of days, hours, and minutes or 
you can view logs by selecting a start and ending date and time. 


You can select the levels of logs that you want. Your choices are: All, Fatal, Error, Warn, Info, and 
Debug. 


You can also choose the source of the files that you want to view. Select either Backend or GUI. 


View the Back-end Log 


Step 1 Click the appropriate radio button: 
e Last: The present time minus the number of days, hours, and minutes entered. 
e Start/End: Absolute literal time ranges defined by the date to the minute. 
Step2 Select user, group, etc. 
Step 3 Select the source. 
Step4 Click Submit. 
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Viewing the Audit Trail 


You can track the activities of the appliance’s users by analyzing the appliance’s log files. To set the 
appliance’s audit trail logs, navigate to Admin > System Maintenance > View Audit Trail. For typical 
use, it is best to leave this page set to its defaults. 


You can view the user audit trails either by selecting a number of days, hours, and minutes, or you can 
view a specific interval by selecting a start and ending date and time. 


View an Audit Trail 


Step 1 Click the appropriate radio button: 

e Last: DD-HH-MM 

e Start/End: YY-MM-DD-HH-MM 
Step2 From the list, select the user or user group. 


Step3 Click Submit. 


Retrieving Raw Messages 


Using this feature, you can retrieve raw messages from either an archive server (see Configuring and 
Performing Appliance Data Backups, page 6-18) or from the database running on the Local Controller. 
These two method offer different advantages: 


e Archive server. Retrieving raw messages, or event data, from an archive server is much faster than 
retrieving from the database. Therefore, it is the recommended option if it is available and it covers 
the time period you are investigating. However, this option is only available if you have enabled data 
archiving and waited the requisite time for the initial archival operation to occur; it is a scheduled 
operation that runs nightly around 2:00 a.m. Once the initial archive is performed, the event data is 
written to the archive server every hour. That data is not archived in real-time identifies another 
limitation to this option, and that is the historical period that can be studied. If you need to view data 
that is more current than an hour old, you should select the Database option to ensure that correct 
data is retrieved. For all other periods, the archive server option is recommended. To enable 
archiving, see Configuring and Performing Appliance Data Backups, page 6-18. 


e Database. Retrieving event data from the database provides slower performance than the archive 
server. However, it provides access to the most current data received. When you select this option, 
you can specify where you want the retrieved records to be written: in the default local directory or 
the a remote server, if one is available. 


This section contains the following topics: 
e Retrieve Raw Messages From Archive Server, page 24-3 


e Retrieve Raw Messages From the Database of a Local Controller, page 24-5 


Retrieve Raw Messages From Archive Server 


Use this selection if archiving is enabled. 


User Guide for Cisco Security MARS Local Controller 
| 78-17020-01 mw 24-3 


Chapter 24 System Maintenance | 


HI Retrieving Raw Messages 


To retrieve event data from an archive server, follow these steps: 


Step 1 Click Admin > System Maintenance > Retrieve Raw Messages. 


Retrieve Raw Messages: 


Specify Time Range: 


c Start: | 2005 ¥]|| october ¥i[7 V\F__Jurs[t2_|mins[is__]secs 


End: [2005 lll October M7 i[7__]Hrs[22__]mins[1s_]secs 


@ Retrieve Data From Archived Files 


c Retrieve Data From DB 


C Save To Local G@ Save To Remote 


[7 Force Generate Files Maximum No. of Files: fio _ | 


Select Reporting Device: 


143783 


Step2 Specify the time range by specifying values in the Start and End fields. 
Step3 Verify that Retrieve Data From Archived Files is selected. 


The data will be retrieved from the server identified under Admin > System Maintenance > Data 
Archiving. 


Step4 Click Submit. 


Note While MARS is generating your files, you can still use the system for other tasks. 


Result: The Retrieving Progress 0% screen appears. When the operation is complete, the Raw Message 
Files screen appears, identifying a new Gzip archive file with a filename based on specified time range. 


Get More Files 


Raw Message Files Download 
. Lind 
2005-10-07-06-14-28_2005-10-08-06-24-28.g2 Click Here to Download © 
© 
wT 


Step5 To download and view the generated raw message file, click Click Here to Download next to the 
filename. 


The filename adheres to the following syntax: 
YYYY-MM-DD-HH-MM-SS_YYYY-MM-DD-HH-MM-SS.gz. 


Step6 |= Use WinZip or another archive expansion program to extract the contents of the Gzip archive file. 


Step7 Once the textfile is extracted from the GNU Zip archive format, its contents resemble the following: 


33750»Wed Jul 27 16:16:06 PDT 2005»BR-FW-1»10.4.1.1 Mon Jan 6 11:05:34 2003 <134>Jan 06 
2003 11:03:53: %PIX-6-302001: Built inbound TCP connection 21000 for faddr 10.1.2.4/9000 
gaddr 10.1.5.20/80 laddr 10.1.5.20/80 


where it reads: device ID>>date>>device name>>raw message. 
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Note 


If you see Chinese or other unfamiliar characters in the resulting text file, please use Microsoft Internet 
Explorer to view the file and verify that the Western European ISO or Western European Windows 
encoding value is selected (View > Encoding). The “»” sign appears correctly as a separator when a 
compatible encoding is selected. 


Retrieve Raw Messages From the Database of a Local Controller 


Step 1 


Step 2 
Step 3 
Step 4 


Step 5 


Use this selection if archiving is not enabled or if you need to view event data that was received within 
the past hour. 


To retrieve event data from the database, follow these steps: 


Click Admin > System Maintenance > Retrieve Raw Messages. 


Retrieve Raw Messages: 


Specify Time Range: 


© start:[2005 W)[ October [7 [7 ]Hrs[t2__]mins 
End: [2005 W][ October 7 M\[F__]Hrs[22__]mins 


@ Retrieve Data From Archived Files 


ft Retrieve Data From DB 


( Save To Local @ Save To Remote 


jv Force Generate Files Maximum No, of Files: 


Select Reporting Device: 


| All Devices v 


143784 


Specify the time range by specifying values in the Start and End fields. 
Select Retrieve from Database. 
Select one of the following options: 
e Save to Local. This option retrieves the data from the database and stores it on the local appliance. 


e Save to Remote. This option retrieves the data from the database and stores it on the archive server, 
as identified under Admin > System Maintenance > Data Archiving. 


Review the Cached Files time range information, and then do one of the following: 
e If you want data from within this time range, you do not need for Force Generate Files. 


e If you want data that does not fall within the Cached Files time range, select the Force Generate 
Files check box. 


e If there is no cached file information, select the Force Generate Files check box. 


If no cached file data is shown, then no previous queries have been performed and stored. For example, 
if you preform three separate queries, using time range A, from the database using the time range, saving 
the files to the local MARS Appliance. If you later specify the same time range A and do the retrieval 
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again but you do not clear the Force generate files check box, the system performs the query, generating 
the file again. However, if you have already retrieved and stored some data before, you can specify to 
retrieve them from those saved files by clearing the Force generate files check box. 


Step6 Enter the maximum number of retrieved files to retain in the Maximum No. of Files field. 


This value refers to the maximum number of event files to be generated for this query. 


Note Requesting large numbers of files can take some time. 


Step7 Select the list of devices for which you want to pull event data in the Reporting Devices list. 
You can select a specific device by name or All Devices. 


Step8 Click Submit. 


Note While MARS is generating your files, you can still use the system for other tasks. 


Result: The Retrieving Progress 0% screen appears. When the operation is complete, the Raw Message 
Files screen appears, identifying a new Gzip archive file with a filename based on specified time range. 


| Get More Files 


Raw Message Files Download 


143797 


Step9 To download and view the generated raw message file, click Click Here to Download next to the 
filename. 


The filename adheres to the following syntax: 
YY Y Y-MM-DD-HH-MM-SS_YYYY-MM-DD-HH-MM-SS.gz. 


Step10 Use WinZip or another archive expansion program to extract the contents of the Gzip archive file. 
Step11_ Once the textfile is extracted from the GNU Zip archive format, its contents resemble the following: 


33750>Wed Jul 27 16:16:06 PDT 2005»BR-FW-1>»10.4.1.1 Mon Jan 6 11:05:34 2003 <134>Jan 06 
2003 11:03:53: %PIX-6-302001: Built inbound TCP connection 21000 for faddr 10.1.2.4/9000 
gaddr 10.1.5.20/80 laddr 10.1.5.20/80 


where it reads: device ID>>date>>device name>>raw message. 


Note If you see Chinese or other unfamiliar characters in the resulting text file, please use Microsoft Internet 
Explorer to view the file and verify that the Western European ISO or Western European Windows 


encoding value is selected (View > Encoding). The “»” sign appears correctly as a separator when a 
compatible encoding is selected. 
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Hard Drives 


Status Lights 


Depending on the model of the appliance, each hard drive has two status lights under or next to the drive. 
The following states can be determined based on the status lights: 


e A steady green light indicates that the drive is functioning normally. 
e A blinking orange light indicates that the drive is performing I/O operations. 


e No light indicates that the disk has no power. 


Partition Checking 


The appliance automatically runs checks on different partitions of the hard drive after the system has 
been re-booted 25 - 30 times, or if the appliance has not been re-booted in 180 days. 


Hotswapping Hard Drives 


If a hard drive fails in the MARS 50, 100, 100e, 200, GC, or GCm appliance models, the MARS 
administrator receives an e-mail notification. The notification identifies the drive number of the failed 
hard drive. 


Remove a Hard Drive 


Step 1 Log in through the CLI tool. 
Step2 Enter the hotswap command. 
Step3 Remove the hard drive. 

Step4 Replace a Hard Drive, page 24-7 


Replace a Hard Drive 


Step 1 Use the door key to open the chassis door. 

Step2 —__ Use the drive bay key to unlock the drive bay you want to change. 
Step3 —- Pull out the drive. 

Step4 | Use a screwdriver to remove the drive bay holder from the hard drive. 
Step5 = Put the new hard drive in the drive bay holder, screwing it into place. 
Step6 Gently push the drive into the place you removed it from. 

Step7 Lock the drive bay back into place. 

Step8 Close the bay door, and re-lock it. 
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wy 


Note Youcan only swap one hard drive at a time. Make sure to verify the system has completed the initializing 
of the new hard drive before swapping another hard drive. 


Replacing the Lithium Cell CMOS Battery 
AN 


Caution A risk of explosion exists if you replace the lithium cell cmos battery with the incorrect type. Never try 
to replace the Lithium Cell CMOS battery. If this battery needs replacement, contact Cisco for more 
information. 


Replace the Lithium Cell CMOS Battery 
& 


Note Take proper electrostatic discharge (ESD) measures before physically touching the appliance. 


If the CMOS battery needs replacement, follow these steps: 


Step 1 Turn the appliance’s power off. 

Step2 | Unplug the appliance from the wall electrical socket. 
Step3 Locate the lithium cell CMOS battery. 

Step4 Remove it. 

Step5 Set the new battery in its place. 

Step6 Plug the appliance into the electrical socket in the wall. 


Step7 ‘Turn the appliance’s power on. 


Note The lithium battery can be harmful to the environment. Contact your local waste disposal service for 
information about safely disposing of the battery. 


Change the Default Password of the Administrator Account 


Good security practices require that you change the default password. We recommend using strong 
passwords for the MARS Appliance appliances. 


Login names and passwords: 
e can be alphanumeric characters 


e are case sensitive 
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Step 1 
Step 2 
Step 3 
Step 4 


Change the Default Password of the Administrator Account Hi 


e can contain special characters (!, @, #, etc.) 


¢ cannot contain single or double quotes (‘or “) 


Login names can contain up to 20 characters. Passwords can contain up to 64 characters. 


To change the default password and setup administrator notification, follow these steps: 


Click the Management > User Management tab. 


Check the box next to Administrator, and click Edit. 


Enter the new Administrator password and the Administrator e-mail address. 


Click Submit. 
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Cisco Security MARS XML API Reference 


This appendix provides resources for creating XML applications that integrate Cisco Security MARS 


XML data into third-party applications. 


XML Overview 


The XML schema are written in conformance with the standard World Wide Web Consortium (W3C) 
XML schema language. A schema by definition, describes all data and data structures required to create 
your application. Many XML development environments provide enough capability to view the schema 
in a way that you can identify all components, their relationships, constraints, attributes, annotations, 
and usage guidelines at a glance. Some applications generate hyperlinked reference documentation. By 
providing sufficient documentation and annotation tags within the schemas, Cisco supports such 
documentation generating applications. 


Table A-1 lists resources for XML development. The list is not exhaustive nor an endorsement by Cisco 


of any particular product. 


Table A-1 XML Resources 


Resource Description 


URL 


Latest Cisco Security MARS Schemas 


http://www.cisco.com/cgi-bin/tablebuild.pl/cs-m 
ars 


W3C XML Schema standards forum with 
resource links 


http://www.w3.org/XML/Schema 


General XML description with resource links 


http://en.wikipedia.org/wiki/Xml 


Online XML Tutorials 


http://www.w3schools.com/xml/default.asp 


XML Documentation Generators (generates 
hyperlinked command references from any 
schema) 


http://lists.w3.org/Archives/Public/xmlschema-d 
ev/2006Feb/0050.html 


http://www.stylusstudio.com/xml_schema_doc_g 
en.html 


XMLSpy® XML development software 


http://www.altova.com/products.html 


I 78-17020-01 


User Guide for Cisco Security MARS Local Controller | 


Appendix A Cisco Security MARS XML API Reference | 


HE XML Incident Notification Data File and Schema 


XML Incident Notification Data File and Schema 


XML incident notification sends an email notification of an incident with an attached XML data file. The 
XML data file contains all incident details that can be viewed on the GUI except for Path/Mitigation data. 
The XML data file can be sent as a plain-text file or as a compressed gzip file. The filename is 
constructed with the incident ID number, for example cs-mars-Incident-13725095.xml. The 
compressed version of the same data file would be cs-MaRS-Incident-13725095.xml.gz 


An XML application can be written to parse and extract data from the XML incident notification data 
file for integration into third-party software, such as a trouble ticketing system, or helpdesk software. 


Table A-2 lists the documentation for the Cisco Security MARS XML incident notification feature. 


Table A-2 Related XML Incident Notification Documents 


Resource Description Resource Location 


Configuring XML incident notification on MARS |Chapter 22, “Sending Alerts and Incident 
Notifications” 


A ZIP file containing the XML incident TBD 
notification schema 


A hyper-linked component reference, generated |TBD 
from the XML incident notification schema 


Sample XML incident notification data generated |Appendix A, “Example A-1 
by MARS 


XML Incident Notification Data File Sample Output 


Example A-1 is XML incident notification data generated by the events that trigger the rule “CS-MARS 
Database Partition Usage.” 


Example A-1_ XML Incident Notification Data File Contents 


<?xml version="1.0" encoding="UTF-8"?> 
<CSMARS-NOTIFICATION> 
<Header> 
<Version>1.0</Version> 
<GenTimeStamp>May 15, 2006 8:48:02 AM PDT</GenTimeStamp> 
<CSMARSHostIpAddr_eth0>10.2.3.7</CSMARSHostIpAddr_eth0> 
<CSMARSHostIpAddr_eth1>192.168.1.101</CSMARSHostIpAddr_eth1> 
<CSMARSHostName>MyLatest</CSMARSHostName> 
<CSMARSZoneName /> 
<CSMARSVersion>4.2.1</CSMARSVersion> 
</Header> 
<Data> 
<Incident id="597842933"> 
<StartTime>May 15, 2006 8:47:26 AM PDT</StartTime> 
<EndTime>May 15, 2006 8:47:26 AM PDT</EndTime> 
<Severity>LOW</Severity> 
<Session id="597744001"> 
<Instance>0</Instance> 
<RuleOffset>1</RuleOffset> 
<SessionEndPoints> 
<Source ipaddress="0.0.0.0" /> 
<Destination ipaddress="10.2.3.7" /> 
<SourcePort>0</SourcePort> 
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<DestinationPort>0</DestinationPort> 
<Protocol>-1</Protocol> 
</SessionEndPoints> 
<Event id="597744001"> 
<EventType id="125755" /> 
<TimeStamp>May 15, 2006 8:47:26 AM PDT</TimeStamp> 
<ReportingDevice id="50" /> 


<RawMessage>Mon May 15 08:47:26 PDT 2006 &1t;13&gt;%MARS-3-100026 CS-MARS 
MyLatest : Current database partition pn_event_session_8 utililization has reached 75%; 


next database partition pn_event_session_9 containing data between Thu Apr 20 11:59:13 PDT 
2006 and Fri Apr 21 11:32:17 PDT 2006 will be purged approximately at Mon May 15 11:56:02 


PDT 2006.</RawMessage> 
<FalsePositiveType>NOT_AVAILABLE</FalsePositiveType> 
<EventEndPoints> 

<Source ipaddress="0.0.0.0" /> 
<Destination ipaddress="10.2.3.7" /> 
<SourcePort>0</SourcePort> 
<DestinationPort>0</DestinationPort> 
<Protocol>-1</Protocol> 
</EventEndPoints> 
<NATtedEndPoints> 
<Source ipaddress="0.0.0.0" /> 
<Destination ipaddress="10.2.3.7" /> 
<SourcePort>0</SourcePort> 
<DestinationPort>0</DestinationPort> 
<Protocol>-1</Protocol> 
</NATtedEndPoints> 
<FiringEventFlag>true</FiringEventFlag> 
</Event> 
</Session> 
“Rule, id="134473"> 
<Name>System Rule: CS-MARS Database Partition Usage</Name> 


<Description>This rule indicates that the current CS-MARS database partition 
filled up to 75% of its capacity and the next database partition will be purged soon to 
create space for new events. The estimated purge times are in the event message. 


normal CS-MARS activity and will result in old events and incidents to purged from CS-MARS 


database. Users are urged to archive CS-MARS data to prevent permanent data 


loss.</Description> 
</Rule> 
<NetworkAddressObj id="0"> 
<IPAddress>0.0.0.0</IPAddress> 
<MAC /> 
<DNSName /> 
<DynamicInfo> 
<HostName /> 
MACAddress /> 
AAAUser /> 
EnforcementDeviceAndPort /> 
ReportingDevice /> 
StartTime>Dec 31, 1969 4:00:00 PM PST</StartTime> 
EndTime>Dec 31, 1969 4:00:00 PM PST</EndTime> 
<UpdateTime>Dec 31, 1969 4:00:00 PM PST</UpdateTime> 
</DynamicInfo> 
</NetworkAddressObj> 
<NetworkAddressObj id="167904007"> 
<IPAddress>10.2.3.7</IPAddress> 
<MAC> 
<MACAddress>00:30:48:83:25:d9</MACAddress> 
<LastUpdateTime>May 15, 2006 6:59:09 AM PDT</LastUpdateTime> 
</MAC> 
<DNSName>MyLatest</DNSName> 
<Device id="50" /> 
<DynamicInfo> 
<HostName /> 


AAAAAA 
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<MACAddress /> 
<AAAUser /> 
EnforcementDeviceAndPort /> 
ReportingDevice /> 
StartTime>Dec 31, 1969 4:00:00 PM PST</StartTime> 
EndTime>Dec 31, 1969 4:00:00 PM PST</EndTime> 
UpdateTime>Dec 31, 1969 4:00:00 PM PST</UpdateTime> 
</DynamicInfo> 
</NetworkAddressObj> 
<EventTypeObj id="125755"> 
<Name>1000029</Name> 
<Description>CS-MARS DB partition filling up causing the next partition to be 
purged soon</Description> 
<Severity>LOW</Severity> 
<CVE /> 
</EventTypeObj> 
<DeviceObj id="50"> 
<Name>MyLatest</Name> 
<NetBiosName /> 
<DefaultGateway>10.2.3.1</DefaultGateway> 
<OperatingSystem id="0" /> 
<InterfaceAddressObj id="117924"> 
<Name>eth0</Name> 
<IPAddress>10.2.3.7</IPAddress> 
<MAC> 
<MACAddress>00:30:48:83:25:d9</MACAddress> 
<LastUpdateTime>May 15, 2006 6:59:09 AM PDT</LastUpdateTime> 
</MAC> 
</InterfaceAddressObj> 
<InterfaceAddressObj id="123040"> 
<Name>eth1</Name> 
<IPAddress>192.168.1.101</IPAddress> 
<MAC /> 
</InterfaceAddressObj> 
</DeviceObj> 
</Incident> 
</Data> 
</CSMARS-NOTIFICATION> 


< 
< 
< 
< 


A 


XML Incident Notification Schema 
The XML incident notification schema document (csmars-incident-notification.xsd) can be downloaded 
from the the following URL: 
http://www.cisco.com/TBD 


Usage Guidelines and Conventions for XML Incident Notification 


All XML incident notification elements are defined in the XML incident notification schema. A 
component reference document generated from the schema is available for your convenience at the 
following URL: 


URL TBD 


You can generate a similar document with the application of your choice, or view components, their 
relationships, constraints, attributes, annotations, and usage guidelines within your XML development 
environment. 
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MARS uses a best effort approach to create XML incident notification data. If an error occurs during 
data compilation, MARS does not stop the process, but sends the data, even if it is partial. Validating the 
data file against the schema would result in errors for these cases. 


The following conventions are observed for XML incident notification data: 
e Character encoding is Unicode Transformation Format 8 (UTF-8) 
e The reported time zone would be the time zone of the local controller reporting the incident 


e Raw messages from reporting devices are XML-escaped in the data file. Your XML parser should 
be able to unescape XML data. 


e If there is no value for an element available from MARS, the element is included in the data file as 
an empty node. For instance, a DNS name may not be available for a device. 


e All date formats are Mmm dd, yyyy hh:mm:ss AM TZD 
- Mmm is the month (Jan, Feb, Mar. . . Dec) 
- dd is the day (1-9, 10-31) 
- yyyy is the year (0000-9999) 
- hh:mm:ss is hours, minutes, seconds 
hh are 1-9, 10-12 
mm are 00-60 
ss are 00-60 
- AMor PM 
- TZD is time zone designator (PDT, PST, MDT, MST, etc.) 
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APPENDIX 
Regular Expression Reference 


e PCRE Regular Expression Details, page B-1 

e Backslash, page B-2 

e Circumflex and Dollar, page B-7 

e Full Stop (Period, Dot), page B-8 

e Matching a Single Byte, page B-8 

e Square Brackets and Character Classes, page B-8 
e Posix Character Classes, page B-9 

e Vertical Bar, page B-10 

e Internal Option Setting, page B-10 

e Subpatterns, page B-11 

e Named Subpatterns, page B-12 

e Repetition, page B-12 

e Atomic Grouping and Possessive Quantifiers, page B-14 
e Back References, page B-15 

e Assertions, page B-16 

e¢ Conditional Subpatterns, page B-19 

e Comments, page B-20 

e Recursive Patterns, page B-20 

e Subpatterns as Subroutines, page B-21 


e Callouts, page B-22 


PCRE Regular Expression Details 


The syntax and semantics of the regular expressions supported by PCRE are described below. Regular 
expressions are also described in the Perl documentation and in a number of books, some of which have 
copious examples. Jeffrey Friedl's "Mastering Regular Expressions", published by O'Reilly, covers 
regular expressions in great detail. This description of PCRE's regular expressions is intended as 
reference material. 
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Backslash 


The original operation of PCRE was on strings of one-byte characters. However, there is now also 
support for UTF-8 character strings. To use this, you must build PCRE to include UTF-8 support, and 
then call pcre_compile() with the PCRE_UTF$8 option. How this affects pattern matching is mentioned 
in several places below. There is also a summary of UTF-8 features in the section on UTF-8 support in 
the main PCRE page. 


A regular expression is a pattern that is matched against a subject string from left to right. Most 
characters stand for themselves in a pattern, and match the corresponding characters in the subject. As 
a trivial example, the pattern 


The quick brown fox 


matches a portion of a subject string that is identical to itself. The power of regular expressions comes 
from the ability to include alternatives and repetitions in the pattern. These are encoded in the pattern by 
the use of metacharacters, which do not stand for themselves but instead are interpreted in some special 
way. 


There are two different sets of metacharacters: those that are recognized anywhere in the pattern except 
within square brackets, and those that are recognized in square brackets. Outside square brackets, the 
metacharacters are as follows: 


\ general escape character with several uses 
assert start of string (or line, in multiline mode) 
$ assert end of string (or line, in multiline mode) 
match any character except newline (by default) 
[ start character class definition 
| start of alternative branch 
( start subpattern 
) end subpattern 
? extends the meaning of ( 
also 0 or 1 quantifier 
also quantifier minimizer 


* 0 or more quantifier 
+ 1 or more quantifier 

also "possessive quantifier" 
{ start min/max quantifier 


Part of a pattern that is in square brackets is called a "character class". In a character class the only 
metacharacters are: 


N general escape character 
my negate the class, but only if the first character 
- indicates character range 
[ POSIX character class (only if followed by POSIX syntax) 
] terminates the character class 


The following sections describe the use of each of the metacharacters. 


The backslash character has several uses. Firstly, if it is followed by a non-alphanumeric character, it 
takes away any special meaning that character may have. This use of backslash as an escape character 
applies both inside and outside character classes. 


For example, if you want to match a * character, you write \* in the pattern. This escaping action applies 
whether or not the following character would otherwise be interpreted as a metacharacter, so it is always 
safe to precede a non-alphanumeric with backslash to specify that it stands for itself. In particular, if you 
want to match a backslash, you write \\. 
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If a pattern is compiled with the PCRE_EXTENDED option, whitespace in the pattern (other than in a 
character class) and characters between a # outside a character class and the next newline character are 
ignored. An escaping backslash can be used to include a whitespace or # character as part of the pattern. 


If you want to remove the special meaning from a sequence of characters, you can do so by putting them 
between \Q and \E. This is different from Perl in that $ and @ are handled as literals in \Q...\E sequences 
in PCRE, whereas in Perl, $ and @ cause variable interpolation. Note the following examples: 


Pattern PCRE matches Perl matches 

\QabcS$xyz\E abcSxyz abc followed by the contents of Sxyz 
\Qabc\S$xyz\E abc\S$xyz abc\$xyz 

\Qabc\E\$\Qxyz\E abcSxyz abcSxyz 


The \Q...\E sequence is recognized both inside and outside character classes. 


Non-printing Characters 


A second use of backslash provides a way of encoding non-printing characters in patterns in a visible 
manner. There is no restriction on the appearance of non-printing characters, apart from the binary zero 
that terminates a pattern, but when a pattern is being prepared by text editing, it is usually easier to use 
one of the following escape sequences than the binary character it represents: 


\a alarm, that is, the BEL character (hex 07) 

\cox "control-x", where x is any character 

\e escape (hex 1B) 

\f formfeed (hex 0C) 

\n newline (hex OA) 

Ae carriage return (hex OD) 

Nt tab (hex 09) 

\ddd character with octal code ddd, or backreference 
\xhh character with hex code hh 

\x{hhh..} character with hex code hhh... (UTF-8 mode only) 


The precise effect of \cx is as follows: if x is a lower case letter, it is converted to upper case. Then bit 
6 of the character (hex 40) is inverted. Thus \cz becomes hex 1A, but \c{ becomes hex 3B, while \c; 
becomes hex 7B. 


After \x, from zero to two hexadecimal digits are read (letters can be in upper or lower case). In UTF-8 
mode, any number of hexadecimal digits may appear between \x{ and }, but the value of the character 
code must be less than 2**31 (that is, the maximum hexadecimal value is 7FFFFFFF). If characters other 
than hexadecimal digits appear between \x{ and }, or if there is no terminating }, this form of escape is 
not recognized. Instead, the initial \x will be interpreted as a basic hexadecimal escape, with no 
following digits, giving a character whose value is zero. 


Characters whose value is less than 256 can be defined by either of the two syntaxes for \x when PCRE 
is in UTF-8 mode. There is no difference in the way they are handled. For example, \xdc is exactly the 
same as \x{dc}. 


After \0 up to two further octal digits are read. In both cases, if there are fewer than two digits, just those 
that are present are used. Thus the sequence \O\x\07 specifies two binary zeros followed by a BEL 
character (code value 7). Make sure you supply two digits after the initial zero if the pattern character 
that follows is itself an octal digit. 
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The handling of a backslash followed by a digit other than 0 is complicated. Outside a character class, 
PCRE reads it and any following digits as a decimal number. If the number is less than 10, or if there 
have been at least that many previous capturing left parentheses in the expression, the entire sequence is 
taken as a back reference. A description of how this works is given later, following the discussion of 
parenthesized subpatterns. 


Inside a character class, or if the decimal number is greater than 9 and there have not been that many 
capturing subpatterns, PCRE re-reads up to three octal digits following the backslash, and generates a 
single byte from the least significant 8 bits of the value. Any subsequent digits stand for themselves. For 
example: 


\040 is another way of writing a space 


\40 is the same, provided there are fewer than 40 previous capturing subpatterns 
AE is always a back reference 
\11 might be a back reference, or another way of writing a tab 


\011 is always a tab 

\0113 is a tab followed by the character "3" 

\113 might be a back reference, otherwise the character with octal code 113 

\377 might be a back reference, otherwise the byte consisting entirely of 1 bits 

\81 is either a back reference, or a binary zero followed by the two characters 
"8" and "1" 


Note that octal values of 100 or greater must not be introduced by a leading zero, because no more than 
three octal digits are ever read. 


All the sequences that define a single byte value or a single UTF-8 character (in UTF-8 mode) can be 
used both inside and outside character classes. In addition, inside a character class, the sequence \b is 
interpreted as the backspace character (hex 08), and the sequence \X is interpreted as the character "X". 
Outside a character class, these sequences have different meanings (see Unicode Character Properties, 
page B-5). 


Generic Character Types 


The third use of backslash is for specifying generic character types. The following are always 
recognized: 


\d any decimal digit 

\D any character that is not a decimal digit 

\s any whitespace character 

\S any character that is not a whitespace character 
\w any "word" character 

\w any "non-word" character 


Each pair of escape sequences partitions the complete set of characters into two disjoint sets. Any given 
character matches one, and only one, of each pair. 


These character type sequences can appear both inside and outside character classes. They each match 
one character of the appropriate type. If the current matching point is at the end of the subject string, all 
of them fail, since there is no character to match. 


For compatibility with Perl, \s does not match the VT character (code 11). This makes it different from 
the the POSIX "space" class. The \s characters are HT (9), LF (10), FF (12), CR (13), and space (32). 
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A "word" character is an underscore or any character less than 256 that is a letter or digit. The definition 
of letters and digits is controlled by PCRE's low-valued character tables, and may vary if locale-specific 
matching is taking place (see "Locale support" in the pcreapi page). For example, in the "fr_FR" 
(French) locale, some character codes greater than 128 are used for accented letters, and these are 
matched by \w. 


In UTF-8 mode, characters with values greater than 128 never match \d, \s, or \w, and always match \D, 
\S, and \W. This is true even when Unicode character property support is available. 


Unicode Character Properties 


When PCRE is built with Unicode character property support, three additional escape sequences to 
match generic character types are available when UTF-8 mode is selected. They are: 


\p{xx} a character with the xx property 
\P{xx} a character without the xx property 
\X an extended Unicode sequence 


The property names represented by xx above are limited to the Unicode general category properties. Each 
character has exactly one such property, specified by a two-letter abbreviation. For compatibility with 
Perl, negation can be specified by including a circumflex between the opening brace and the property 
name. For example, \p{*Lu} is the same as \P{Lu}. 


If only one letter is specified with \p or \P, it includes all the properties that start with that letter. In this 
case, in the absence of negation, the curly brackets in the escape sequence are optional; these two 
examples have the same effect: 


\p{L} 
\pL 


The following property codes are supported: 


Cc Other 

Ce Control 

C£ Format 

Cn Unassigned 

Co Private use 

Cs Surrogate 

L Letter 

Ll Lower case letter 
Lm Modifier letter 
Lo Other letter 

Lt Title case letter 
Lu Upper case letter 
M Mark 

Mc Spacing mark 

Me Enclosing mark 
Mn Non-spacing mark 
N Number 

Nd Decimal number 

N1 Letter number 

No Other number 

P Punctuation 

Pc Connector punctuation 
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Pd Dash punctuation 

Pe Close punctuation 
PE Final punctuation 
Pi Initial punctuation 
Po Other punctuation 
Ps Open punctuation 

iS} Symbol 

Sc Currency symbol 


Sk Modifier symbol 
sm Mathematical symbol 
So Other symbol 


wi Separator 

Z1 Line separator 

Zp Paragraph separator 
Zs Space separator 


Extended properties such as "Greek" or "InMusicalSymbols" are not supported by PCRE. 


Specifying caseless matching does not affect these escape sequences. For example, \p{Lu} always 
matches only upper case letters. 


The \X escape matches any number of Unicode characters that form an extended Unicode sequence. \X 
is equivalent to 


(?>\PM\pM* ) 


That is, it matches a character without the "mark" property, followed by zero or more characters with the 
"mark" property, and treats the sequence as an atomic group (see below). Characters with the "mark" 
property are typically accents that affect the preceding character. 


Matching characters by Unicode property is not fast, because PCRE has to search a structure that 
contains data for over fifteen thousand characters. That is why the traditional escape sequences such as 
\d and \w do not use Unicode properties in PCRE. 


Simple Assertions 


The fourth use of backslash is for certain simple assertions. An assertion specifies a condition that has 
to be met at a particular point in a match, without consuming any characters from the subject string. The 
use of subpatterns for more complicated assertions is described below. The backslashed assertions are: 


\b matches at a word boundary 

\B matches when not at a word boundary 

\A matches at start of subject 

\Z matches at end of subject or before newline at end 
\z matches at end of subject 

\G matches at first matching position in subject 


These assertions may not appear in character classes (but note that \b has a different meaning, namely 
the backspace character, inside a character class). 


A word boundary is a position in the subject string where the current character and the previous character 
do not both match \w or \W (i.e. one matches \w and the other matches \W), or the start or end of the 
string if the first or last character matches \w, respectively. 


The \A, \Z, and \z assertions differ from the traditional circumflex and dollar (described in the next 
section) in that they only ever match at the very start and end of the subject string, whatever options are 
set. Thus, they are independent of multiline mode. These three assertions are not affected by the 
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PCRE_NOTBOL or PCRE_NOTEOL options, which affect only the behaviour of the circumflex and 
dollar metacharacters. However, if the startoffset argument of pcre_exec() is non-zero, indicating that 
matching is to start at a point other than the beginning of the subject, \A can never match. The difference 
between \Z and \z is that \Z matches before a newline that is the last character of the string as well as at 
the end of the string, whereas \z matches only at the end. 


The \G assertion is true only when the current matching position is at the start point of the match, as 
specified by the startoffset argument of pere_exec(). It differs from \A when the value of startoffset is 
non-zero. By calling pcre_exec() multiple times with appropriate arguments, you can mimic Perl's /g 
option, and it is in this kind of implementation where \G can be useful. 


Note, however, that PCRE's interpretation of \G, as the start of the current match, is subtly different from 
Perl's, which defines it as the end of the previous match. In Perl, these can be different when the 
previously matched string was empty. Because PCRE does just one match at a time, it cannot reproduce 
this behaviour. 


If all the alternatives of a pattern begin with \G, the expression is anchored to the starting match position, 
and the "anchored" flag is set in the compiled regular expression. 


Circumflex and Dollar 


Outside a character class, in the default matching mode, the circumflex character is an assertion that is 
true only if the current matching point is at the start of the subject string. If the startoffset argument of 
pcre_exec() is non-zero, circumflex can never match if the PCRE_MULTILINE option is unset. Inside 
a character class, circumflex has an entirely different meaning (see Square Brackets and Character 
Classes, page B-8 and Posix Character Classes, page B-9). 


Circumflex need not be the first character of the pattern if a number of alternatives are involved, but it 
should be the first thing in each alternative in which it appears if the pattern is ever to match that branch. 
If all possible alternatives start with a circumflex, that is, if the pattern is constrained to match only at 
the start of the subject, it is said to be an "anchored" pattern. (There are also other constructs that can 
cause a pattern to be anchored.) 


A dollar character is an assertion that is true only if the current matching point is at the end of the subject 
string, or immediately before a newline character that is the last character in the string (by default). 
Dollar need not be the last character of the pattern if a number of alternatives are involved, but it should 
be the last item in any branch in which it appears. Dollar has no special meaning in a character class. 


The meaning of dollar can be changed so that it matches only at the very end of the string, by setting the 
PCRE_DOLLAR_ENDONLY option at compile time. This does not affect the \Z assertion. 


The meanings of the circumflex and dollar characters are changed if the PCRE_MULTILINE option is 
set. When this is the case, they match immediately after and immediately before an internal newline 
character, respectively, in addition to matching at the start and end of the subject string. For example, 
the pattern /Aabc$/ matches the subject string "def\nabc" (where \n represents a newline character) in 
multiline mode, but not otherwise. Consequently, patterns that are anchored in single line mode because 
all branches start with “ are not anchored in multiline mode, and a match for circumflex is possible when 
the startoffset argument of pere_exec() is non-zero. The PCRE_DOLLAR_ENDONLY option is ignored 
if PCRE_MULTILINE is set. 


Note that the sequences \A, \Z, and \z can be used to match the start and end of the subject in both modes, 
and if all branches of a pattern start with \A it is always anchored, whether PCRE_MULTILINE is set or 
not. 
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Full Stop (Period, Dot) 


Outside a character class, a dot in the pattern matches any one character in the subject, including a 
non-printing character, but not (by default) newline. In UTF-8 mode, a dot matches any UTF-8 character, 
which might be more than one byte long, except (by default) newline. If the PCRE_DOTALL option is 
set, dots match newlines as well. The handling of dot is entirely independent of the handling of 
circumflex and dollar, the only relationship being that they both involve newline characters. Dot has no 
special meaning in a character class. 


Matching a Single Byte 


Outside a character class, the escape sequence \C matches any one byte, both in and out of UTF-8 mode. 
Unlike a dot, it can match a newline. The feature is provided in Perl in order to match individual bytes 
in UTF-8 mode. Because it breaks up UTF-8 characters into individual bytes, what remains in the string 
may be a malformed UTF-8 string. For this reason, the \C escape sequence is best avoided. 


PCRE does not allow \C to appear in lookbehind assertions (described below), because in UTF-8 mode 
this would make it impossible to calculate the length of the lookbehind. 


Square Brackets and Character Classes 


An opening square bracket introduces a character class, terminated by a closing square bracket. A 
closing square bracket on its own is not special. If a closing square bracket is required as a member of 
the class, it should be the first data character in the class (after an initial circumflex, if present) or 
escaped with a backslash. 


A character class matches a single character in the subject. In UTF-8 mode, the character may occupy 
more than one byte. A matched character must be in the set of characters defined by the class, unless the 
first character in the class definition is a circumflex, in which case the subject character must not be in 
the set defined by the class. If a circumflex is actually required as a member of the class, ensure it is not 
the first character, or escape it with a backslash. 


For example, the character class [aeiou] matches any lower case vowel, while [4aeiou] matches any 
character that is not a lower case vowel. Note that a circumflex is just a convenient notation for 
specifying the characters that are in the class by enumerating those that are not. A class that starts with 
a circumflex is not an assertion: it still consumes a character from the subject string, and therefore it fails 
if the current pointer is at the end of the string. 


In UTF-8 mode, characters with values greater than 255 can be included in a class as a literal string of 
bytes, or by using the \x{ escaping mechanism. 


When caseless matching is set, any letters in a class represent both their upper case and lower case 
versions, so for example, a caseless [aeiou] matches "A" as well as "a", and a caseless [Saeiou] does not 
match "A", whereas a caseful version would. When running in UTF-8 mode, PCRE supports the concept 
of case for characters with values greater than 128 only when it is compiled with Unicode property 
support. 


The newline character is never treated in any special way in character classes, whatever the setting of the 
PCRE_DOTALL or PCRE_MULTILINE options is. A class such as [Aa] will always match a newline. 
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The minus (hyphen) character can be used to specify a range of characters in a character class. For 
example, [d-m] matches any letter between d and m, inclusive. If a minus character is required in a class, 
it must be escaped with a backslash or appear in a position where it cannot be interpreted as indicating 
a range, typically as the first or last character in the class. 


It is not possible to have the literal character "]" as the end character of a range. A pattern such as [W-]46] 
is interpreted as a class of two characters ("W" and "-") followed by a literal string "46]", so it would 
match "W46]" or "-46]". However, if the "]" is escaped with a backslash it is interpreted as the end of 
range, so [W-\]46] is interpreted as a class containing a range followed by two other characters. The octal 
or hexadecimal representation of "]" can also be used to end a range. 


Ranges operate in the collating sequence of character values. They can also be used for characters 
specified numerically, for example [\000-\037]. In UTF-8 mode, ranges can include characters whose 
values are greater than 255, for example [\x{ 100}-\x{2ff}]. 


If a range that includes letters is used when caseless matching is set, it matches the letters in either case. 
For example, [W-c] is equivalent to [][\\“_-wxyzabc], matched caselessly, and in non-UTF-8 mode, if 
character tables for the "fr_FR" locale are in use, [\xc8-\xcb] matches accented E characters in both 
cases. In UTF-8 mode, PCRE supports the concept of case for characters with values greater than 128 
only when it is compiled with Unicode property support. 


The character types \d, \D, \p, \P, \s, \S, \w, and \W may also appear in a character class, and add the 
characters that they match to the class. For example, [\dABCDEF] matches any hexadecimal digit. A 
circumflex can conveniently be used with the upper case character types to specify a more restricted set 
of characters than the matching lower case type. For example, the class [‘\W_] matches any letter or 
digit, but not underscore. 


The only metacharacters that are recognized in character classes are backslash, hyphen (only where it 
can be interpreted as specifying a range), circumflex (only at the start), opening square bracket (only 
when it can be interpreted as introducing a POSIX class name - see the next section), and the terminating 
closing square bracket. However, escaping other non-alphanumeric characters does no harm. 


Posix Character Classes 


Perl supports the POSIX notation for character classes. This uses names enclosed by [: and :] within the 
enclosing square brackets. PCRE also supports this notation. For example, 


[01[:alpha:]%] 
matches "0", "1", any alphabetic character, or "%". The supported class names are 


alnum letters and digits 

alpha letters 

ascii character codes 0 - 127 

blank space or tab only 

entrl control characters 

digit decimal digits (same as \d) 

graph printing characters, excluding space 
lower lower case letters 

print printing characters, including space 
punct printing characters, excluding letters and digits 
space white space (not quite the same as \s) 
upper upper case letters 

word "word" characters (same as \w) 


xdigit hexadecimal digits 
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The "space" characters are HT (9), LF (10), VT (11), FF (12), CR (13), and space (32). Notice that this 
list includes the VT character (code 11). This makes "space" different to \s, which does not include VT 
(for Perl compatibility). 


The name "word" is a Perl extension, and "blank" is a GNU extension from Perl 5.8. Another Perl 
extension is negation, which is indicated by a * character after the colon. For example, 


[12[:*digit:]] 
matches "1", "2", or any non-digit. PCRE (and Perl) also recognize the POSIX syntax [.ch.] and [=ch=] 
where "ch" is a "collating element", but these are not supported, and an error is given if they are 
encountered. 


In UTF-8 mode, characters with values greater than 128 do not match any of the POSIX character 
classes. 


Vertical Bar 


Vertical bar characters are used to separate alternative patterns. For example, the pattern 


gilbert |sullivan 
matches either "gilbert" or "sullivan". Any number of alternatives may appear, and an empty alternative 
is permitted (matching the empty string). The matching process tries each alternative in turn, from left 
to right, and the first one that succeeds is used. If the alternatives are within a subpattern (defined below), 
"succeeds" means matching the rest of the main pattern as well as the alternative in the subpattern. 


Internal Option Setting 


The settings of the PCRE_CASELESS, PCRE_MULTILINE, PCRE_DOTALL, and 
PCRE_EXTENDED options can be changed from within the pattern by a sequence of Perl option letters 
enclosed between "(?" and ")". The option letters are 


for PCRE_CASELESS 

for PCRE_MULTILINE 
for PCRE_DOTALL 
for PCRE_EXTENDED 


x HW Bb 


For example, (?im) sets caseless, multiline matching. It is also possible to unset these options by 
preceding the letter with a hyphen, and a combined setting and unsetting such as (?im-sx), which sets 
PCRE_CASELESS and PCRE_MULTILINE while unsetting PCRE_DOTALL and 
PCRE_EXTENDED, is also permitted. If a letter appears both before and after the hyphen, the option is 
unset. 


When an option change occurs at top level (that is, not inside subpattern parentheses), the change applies 
to the remainder of the pattern that follows. If the change is placed right at the start of a pattern, PCRE 
extracts it into the global options (and it will therefore show up in data extracted by the pcre_fullinfo() 
function). 


An option change within a subpattern affects only that part of the current pattern that follows it, so 


(a(?i)b)c 
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matches abc and aBc and no other strings (assuming PCRE_CASELESS is not used). By this means, 
options can be made to have different settings in different parts of the pattern. Any changes made in one 
alternative do carry on into subsequent branches within the same subpattern. For example, 


(a(?i)blc) 


matches "ab", "aB", "c", and "C", even though when matching "C" the first branch is abandoned before 
the option setting. This is because the effects of option settings happen at compile time. There would be 
some very weird behaviour otherwise. 


The PCRE-specific options PCRE_UNGREEDY and PCRE_EXTRA can be changed in the same way 
as the Perl-compatible options by using the characters U and X respectively. The (?X) flag setting is 
special in that it must always occur earlier in the pattern than any of the additional features it turns on, 
even when it is at top level. It is best to put it at the start. 


Subpatterns 


Step 1 


Step 2 


Subpatterns are delimited by parentheses (round brackets), which can be nested. Turning part of a pattern 
into a subpattern does two things: 


It localizes a set of alternatives. For example, the pattern : 


cat (aract|erpillar|) 


wom 


matches one of the words "cat", "cataract", or "caterpillar". Without the parentheses, it would match 


wom 


"cataract", "erpillar" or the empty string. 


It sets up the subpattern as a capturing subpattern. This means that, when the whole pattern matches, that 
portion of the subject string that matched the subpattern is passed back to the caller via the ovector 
argument of pere_exec(). Opening parentheses are counted from left to right (starting from 1) to obtain 
numbers for the capturing subpatterns. 


For example, if the string "the red king" is matched against the pattern 


the ((red|white) (king|queen) ) 
the captured substrings are "red king", "red", and "king", and are numbered 1, 2, and 3, respectively. 


The fact that plain parentheses fulfil two functions is not always helpful. There are often times when a 
grouping subpattern is required without a capturing requirement. If an opening parenthesis is followed 
by a question mark and a colon, the subpattern does not do any capturing, and is not counted when 
computing the number of any subsequent capturing subpatterns. For example, if the string "the white 
queen" is matched against the pattern 


the ((?:red|white) (king| queen) ) 


the captured substrings are "white queen" and "queen", and are numbered | and 2. The maximum number 
of capturing subpatterns is 65535, and the maximum depth of nesting of all subpatterns, both capturing 
and non-capturing, is 200. 


As aconvenient shorthand, if any option settings are required at the start of a non-capturing subpattern, 
the option letters may appear between the "?" and the ":". Thus the two patterns 


(?i:saturday | sunday) 
(?: (?1) saturday | sunday) 
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match exactly the same set of strings. Because alternative branches are tried from left to right, and 
options are not reset until the end of the subpattern is reached, an option setting in one branch does affect 
subsequent branches, so the above patterns match "SUNDAY" as well as "Saturday". 


Named Subpatterns 


Repetition 


Identifying capturing parentheses by number is simple, but it can be very hard to keep track of the 
numbers in complicated regular expressions. Furthermore, if an expression is modified, the numbers may 
change. To help with this difficulty, PCRE supports the naming of subpatterns, something that Perl does 
not provide. The Python syntax (?P<name>...) is used. Names consist of alphanumeric characters and 
underscores, and must be unique within a pattern. 


Named capturing parentheses are still allocated numbers as well as names. The PCRE API provides 
function calls for extracting the name-to-number translation table from a compiled pattern. There is also 
a convenience function for extracting a captured substring by name. For further details see the pcreapi 
documentation. 


Repetition is specified by quantifiers, which can follow any of the following items: 


a literal data character 

the . metacharacter 

the \C escape sequence 

the \X escape sequence (in UTF-8 mode with Unicode properties) 
an escape such as \d that matches a single character 

a character class 

a back reference (see next section) 

a parenthesized subpattern (unless it is an assertion) 


The general repetition quantifier specifies a minimum and maximum number of permitted matches, by 
giving the two numbers in curly brackets (braces), separated by acomma. The numbers must be less than 
65536, and the first must be less than or equal to the second. For example: 


z{2,4} 


matches "zz", "zzz", or "zzzz". A closing brace on its own is not a special character. If the second number 
is omitted, but the comma is present, there is no upper limit; if the second number and the comma are 


both omitted, the quantifier specifies an exact number of required matches. Thus 


[aeiou] {3,} 


matches at least 3 successive vowels, but may match many more, while 


\d{8} 


matches exactly 8 digits. An opening curly bracket that appears in a position where a quantifier is not 
allowed, or one that does not match the syntax of a quantifier, is taken as a literal character. For example, 
{,6} is not a quantifier, but a literal string of four characters. 
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In UTF-8 mode, quantifiers apply to UTF-8 characters rather than to individual bytes. Thus, for example, 
\x{ 100} {2} matches two UTF-8 characters, each of which is represented by a two-byte sequence. 
Similarly, when Unicode property support is available, \X{3} matches three Unicode extended 
sequences, each of which may be several bytes long (and they may be of different lengths). 


The quantifier {0} is permitted, causing the expression to behave as if the previous item and the 
quantifier were not present. 


For convenience (and historical compatibility) the three most common quantifiers have single-character 
abbreviations: 


e is equivalent to {0,} 
+ is equivalent to {1,} 
? is equivalent to {0,1} 


It is possible to construct infinite loops by following a subpattern that can match no characters with a 
quantifier that has no upper limit, for example: 


(azy* 


Earlier versions of Perl and PCRE used to give an error at compile time for such patterns. However, 
because there are cases where this can be useful, such patterns are now accepted, but if any repetition of 
the subpattern does in fact match no characters, the loop is forcibly broken. 


By default, the quantifiers are "greedy", that is, they match as much as possible (up to the maximum 
number of permitted times), without causing the rest of the pattern to fail. The classic example of where 
this gives problems is in trying to match comments in C programs. These appear between /* and */ and 
within the comment, individual * and / characters may appear. An attempt to match C comments by 
applying the pattern 


ENEIENET 


to the string 


/* first comment */ not comment /* second comment */ 


fails, because it matches the entire string owing to the greediness of the .* item. 


However, if a quantifier is followed by a question mark, it ceases to be greedy, and instead matches the 
minimum number of times possible, so the pattern 


ENE PONET 


does the right thing with the C comments. The meaning of the various quantifiers is not otherwise 
changed, just the preferred number of matches. Do not confuse this use of question mark with its use as 
a quantifier in its own right. Because it has two uses, it can sometimes appear doubled, as in 


\d??\d 


which matches one digit by preference, but can match two if that is the only way the rest of the pattern 
matches. 


If the PCRE_UNGREEDY option is set (an option which is not available in Perl), the quantifiers are not 
greedy by default, but individual ones can be made greedy by following them with a question mark. In 
other words, it inverts the default behaviour. 
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When a parenthesized subpattern is quantified with a minimum repeat count that is greater than | or with 
a limited maximum, more memory is required for the compiled pattern, in proportion to the size of the 
minimum or maximum. 


If a pattern starts with .* or .{0,} and the PCRE_DOTALL option (equivalent to Perl's /s) is set, thus 
allowing the . to match newlines, the pattern is implicitly anchored, because whatever follows will be 
tried against every character position in the subject string, so there is no point in retrying the overall 
match at any position after the first. PCRE normally treats such a pattern as though it were preceded by 
\A. 


In cases where it is known that the subject string contains no newlines, it is worth setting 
PCRE_DOTALL in order to obtain this optimization, or alternatively using * to indicate anchoring 
explicitly. 


However, there is one situation where the optimization cannot be used. When .* is inside capturing 
parentheses that are the subject of a backreference elsewhere in the pattern, a match at the start may fail, 
and a later one succeed. Consider, for example: 


(.*)abce\1 
If the subject is "xyz123abc123" the match point is the fourth character. For this reason, such a pattern 
is not implicitly anchored. 


When a capturing subpattern is repeated, the value captured is the substring that matched the final 
iteration. For example, after 


(tweedle[dume] {3}\s*)+ 


has matched "tweedledum tweedledee" the value of the captured substring is "tweedledee". However, if 
there are nested capturing subpatterns, the corresponding captured values may have been set in previous 
iterations. For example, after 


/ (al (b))+/ 


matches "aba" the value of the second captured substring is "b". 


Atomic Grouping and Possessive Quantifiers 


With both maximizing and minimizing repetition, failure of what follows normally causes the repeated 
item to be re-evaluated to see if a different number of repeats allows the rest of the pattern to match. 
Sometimes it is useful to prevent this, either to change the nature of the match, or to cause it fail earlier 
than it otherwise might, when the author of the pattern knows there is no point in carrying on. 


Consider, for example, the pattern \d+foo when applied to the subject line 


123456bar 


After matching all 6 digits and then failing to match "foo", the normal action of the matcher is to try 
again with only 5 digits matching the \d+ item, and then with 4, and so on, before ultimately failing. 
"Atomic grouping" (a term taken from Jeffrey Friedl's book) provides the means for specifying that once 
a subpattern has matched, it is not to be re-evaluated in this way. 


If we use atomic grouping for the previous example, the matcher would give up immediately on failing 
to match "foo" the first time. The notation is a kind of special parenthesis, starting with (?> as in this 
example: 
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(?>\d+) foo 


This kind of parenthesis "locks up" the part of the pattern it contains once it has matched, and a failure 
further into the pattern is prevented from backtracking into it. Backtracking past it to previous items, 
however, works as normal. 


An alternative description is that a subpattern of this type matches the string of characters that an 
identical standalone pattern would match, if anchored at the current point in the subject string. 


Atomic grouping subpatterns are not capturing subpatterns. Simple cases such as the above example can 
be thought of as a maximizing repeat that must swallow everything it can. So, while both \d+ and \d+? 
are prepared to adjust the number of digits they match in order to make the rest of the pattern match, 
(?>\d+) can only match an entire sequence of digits. 


Atomic groups in general can of course contain arbitrarily complicated subpatterns, and can be nested. 
However, when the subpattern for an atomic group is just a single repeated item, as in the example above, 
a simpler notation, called a "possessive quantifier" can be used. This consists of an additional + character 
following a quantifier. Using this notation, the previous example can be rewritten as 


\d++foo 


Possessive quantifiers are always greedy; the setting of the PCRE_UNGREEDY option is ignored. They 
are a convenient notation for the simpler forms of atomic group. However, there is no difference in the 
meaning or processing of a possessive quantifier and the equivalent atomic group. 


The possessive quantifier syntax is an extension to the Perl syntax. It originates in Sun's Java package. 


When a pattern contains an unlimited repeat inside a subpattern that can itself be repeated an unlimited 
number of times, the use of an atomic group is the only way to avoid some failing matches taking a very 
long time indeed. The pattern 


(\D+|<\d+>)*[!?] 


matches an unlimited number of substrings that either consist of non-digits, or digits enclosed in <>, 
followed by either ! or ?. When it matches, it runs quickly. However, if it is applied to 


aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa 


it takes a long time before reporting failure. This is because the string can be divided between the internal 
\D+ repeat and the external * repeat in a large number of ways, and all have to be tried. (The example 
uses [!?] rather than a single character at the end, because both PCRE and Perl have an optimization that 
allows for fast failure when a single character is used. They remember the last single character that is 
required for a match, and fail early if it is not present in the string.) If the pattern is changed so that it 
uses an atomic group, like this: 


((?>\D+) |<\d+>)*[!?] 


sequences of non-digits cannot be broken, and failure happens quickly. 


Back References 


Outside a character class, a backslash followed by a digit greater than 0 (and possibly further digits) is 
a back reference to a capturing subpattern earlier (that is, to its left) in the pattern, provided there have 
been that many previous capturing left parentheses. 
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However, if the decimal number following the backslash is less than 10, it is always taken as a back 
reference, and causes an error only if there are not that many capturing left parentheses in the entire 
pattern. In other words, the parentheses that are referenced need not be to the left of the reference for 
numbers less than 10. See Non-printing Characters, page B-3 for further details of the handling of digits 
following a backslash. 


A back reference matches whatever actually matched the capturing subpattern in the current subject 
string, rather than anything matching the subpattern itself (see Subpatterns as Subroutines, page B-21 
for a way of doing that). So the pattern 


(sens|respons)e and \libility 


matches "sense and sensibility" and "response and responsibility", but not "sense and responsibility". If 
caseful matching is in force at the time of the back reference, the case of letters is relevant. For example, 


((?i)rah)\s+\1 


matches "rah rah" and "RAH RAH", but not "RAH rah", even though the original capturing subpattern 
is matched caselessly. 


Back references to named subpatterns use the Python syntax (?P=name). We could rewrite the above 
example as follows: 


(?<p1>(?i) rah) \s+(?P=p1) 


There may be more than one back reference to the same subpattern. If a subpattern has not actually been 
used in a particular match, any back references to it always fail. For example, the pattern 


(a| (be) )\2 


always fails if it starts to match "a" rather than "bc". Because there may be many capturing parentheses 
in a pattern, all digits following the backslash are taken as part of a potential back reference number. If 
the pattern continues with a digit character, some delimiter must be used to terminate the back reference. 
If the PCRE_EXTENDED option is set, this can be whitespace. Otherwise an empty comment (see 
Comments, page B-20) can be used. 


A back reference that occurs inside the parentheses to which it refers fails when the subpattern is first 
used, so, for example, (a\l) never matches. However, such references can be useful inside repeated 
subpatterns. For example, the pattern 


(alb\1)+ 


mom 


matches any number of "a"s and also "aba", "ababbaa" etc. At each iteration of the subpattern, the back 
reference matches the character string corresponding to the previous iteration. In order for this to work, 
the pattern must be such that the first iteration does not need to match the back reference. This can be 
done using alternation, as in the example above, or by a quantifier with a minimum of zero. 


An assertion is a test on the characters following or preceding the current matching point that does not 
actually consume any characters. The simple assertions coded as \b, \B, \A, \G, \Z, \z, * and $ are 
described above. 
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More complicated assertions are coded as subpatterns. There are two kinds: those that look ahead of the 
current position in the subject string, and those that look behind it. An assertion subpattern is matched 
in the normal way, except that it does not cause the current matching position to be changed. 


Assertion subpatterns are not capturing subpatterns, and may not be repeated, because it makes no sense 
to assert the same thing several times. If any kind of assertion contains capturing subpatterns within it, 
these are counted for the purposes of numbering the capturing subpatterns in the whole pattern. However, 
substring capturing is carried out only for positive assertions, because it does not make sense for negative 
assertions. 


Lookahead Assertions 


Lookahead assertions start with (?= for positive assertions and (?! for negative assertions. For example, 


\wt (?=;) 


matches a word followed by a semicolon, but does not include the semicolon in the match, and 


foo(?!bar) 


matches any occurrence of "foo" that is not followed by "bar". Note that the apparently similar pattern 


(?! £00) bar 


does not find an occurrence of "bar" that is preceded by something other than "foo"; it finds any 
occurrence of "bar" whatsoever, because the assertion (?!foo) is always true when the next three 
characters are "bar". A lookbehind assertion is needed to achieve the other effect. 


If you want to force a matching failure at some point in a pattern, the most convenient way to do it is 
with (?!) because an empty string always matches, so an assertion that requires there not to be an empty 
string must always fail. 


Lookbehind Assertions 


Lookbehind assertions start with (?<= for positive assertions and (?<! for negative assertions. For 
example, 


(?<!f00) bar 


does find an occurrence of "bar" that is not preceded by "foo". The contents of a lookbehind assertion 
are restricted such that all the strings it matches must have a fixed length. However, if there are several 
alternatives, they do not all have to have the same fixed length. Thus 


(?<=bullock | donkey) 


is permitted, but 


(?<!dogs?|cats?) 


causes an error at compile time. Branches that match different length strings are permitted only at the 
top level of a lookbehind assertion. This is an extension compared with Perl (at least for 5.8), which 
requires all branches to match the same length of string. An assertion such as 
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(?<=ab(c|de) ) 


is not permitted, because its single top-level branch can match two different lengths, but it is acceptable 
if rewritten to use two top-level branches: 


(?<=abc | abde) 


The implementation of lookbehind assertions is, for each alternative, to temporarily move the current 
position back by the fixed width and then try to match. If there are insufficient characters before the 
current position, the match is deemed to fail. 


PCRE does not allow the \C escape (which matches a single byte in UTF-8 mode) to appear in 
lookbehind assertions, because it makes it impossible to calculate the length of the lookbehind. The \X 
escape, which can match different numbers of bytes, is also not permitted. 


Atomic groups can be used in conjunction with lookbehind assertions to specify efficient matching at 
the end of the subject string. Consider a simple pattern such as 


abcds 


when applied to a long string that does not match. Because matching proceeds from left to right, PCRE 
will look for each "a" in the subject and then see if what follows matches the rest of the pattern. If the 
pattern is specified as 


“.*abcds 


the initial .* matches the entire string at first, but when this fails (because there is no following "a"), it 
backtracks to match all but the last character, then all but the last two characters, and so on. Once again 
the search for "a" covers the entire string, from right to left, so we are no better off. However, if the 
pattern is written as 


“(2?>.%*) (?<=abcd) 


or, equivalently, using the possessive quantifier syntax, 


“ *+(?<=abcd) 


there can be no backtracking for the .* item; it can match only the entire string. The subsequent 
lookbehind assertion does a single test on the last four characters. If it fails, the match fails immediately. 
For long strings, this approach makes a significant difference to the processing time. 


Using Multiple Assertions 


Several assertions (of any sort) may occur in succession. For example, 


(?<=\d{3}) (?<!999) foo 


matches "foo" preceded by three digits that are not "999". Notice that each of the assertions is applied 
independently at the same point in the subject string. First there is a check that the previous three 
characters are all digits, and then there is a check that the same three characters are not "999". This 
pattern does not match "foo" preceded by six characters, the first of which are digits and the last three 
of which are not "999". For example, it doesn't match "123abcfoo". A pattern to do that is 
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(?<=\d{3}...) (?<!999) foo 


This time the first assertion looks at the preceding six characters, checking that the first three are digits, 
and then the second assertion checks that the preceding three characters are not "999". 


Assertions can be nested in any combination. For example, 


(?<=(?<!foo0) bar) baz 


matches an occurrence of "baz" that is preceded by "bar" which in turn is not preceded by "foo", while 


(?<=\d{3}(?!999)...) £00 


is another pattern that matches "foo" preceded by three digits and any three characters that are not "999". 


Conditional Subpatterns 


It is possible to cause the matching process to obey a subpattern conditionally or to choose between two 
alternative subpatterns, depending on the result of an assertion, or whether a previous capturing 
subpattern matched or not. The two possible forms of conditional subpattern are 


(? (condition) yes-pattern) 
(? (condition) yes-pattern|no-pattern) 


If the condition is satisfied, the yes-pattern is used; otherwise the no-pattern (if present) is used. If there 
are more than two alternatives in the subpattern, a compile-time error occurs. 


There are three kinds of condition. If the text between the parentheses consists of a sequence of digits, 
the condition is satisfied if the capturing subpattern of that number has previously matched. The number 
must be greater than zero. Consider the following pattern, which contains non-significant white space to 
make it more readable (assume the PCRE_EXTENDED option) and to divide it into three parts for ease 
of discussion: 


The first part matches an optional opening parenthesis, and if that character is present, sets it as the first 
captured substring. The second part matches one or more characters that are not parentheses. The third 
part is a conditional subpattern that tests whether the first set of parentheses matched or not. If they did, 
that is, if subject started with an opening parenthesis, the condition is true, and so the yes-pattern is 
executed and a closing parenthesis is required. Otherwise, since no-pattern is not present, the subpattern 
matches nothing. In other words, this pattern matches a sequence of non-parentheses, optionally 
enclosed in parentheses. 


If the condition is the string (R), it is satisfied if a recursive call to the pattern or subpattern has been 
made. At "top level", the condition is false. This is a PCRE extension. Recursive patterns are described 
in the next section. 


If the condition is not a sequence of digits or (R), it must be an assertion. This may be a positive or 
negative lookahead or lookbehind assertion. Consider this pattern, again containing non-significant 
white space, and with the two alternatives on the second line: 


(2? (?=[*a-z]*[a-z]) 
\d{2}-[a-z]{3}-\d{2} | \d{2}-\d{2}-\d{2} ) 
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The condition is a positive lookahead assertion that matches an optional sequence of non-letters followed 
by a letter. In other words, it tests for the presence of at least one letter in the subject. If a letter is found, 
the subject is matched against the first alternative; otherwise it is matched against the second. This 
pattern matches strings in one of the two forms dd-aaa-dd or dd-dd-dd, where aaa are letters and dd are 
digits. 


The sequence (?# marks the start of a comment that continues up to the next closing parenthesis. Nested 
parentheses are not permitted. The characters that make up a comment play no part in the pattern 
matching at all. 


If the PCRE_EXTENDED option is set, an unescaped # character outside a character class introduces a 
comment that continues up to the next newline character in the pattern. 


Recursive Patterns 


Consider the problem of matching a string in parentheses, allowing for unlimited nested parentheses. 
Without the use of recursion, the best that can be done is to use a pattern that matches up to some fixed 
depth of nesting. It is not possible to handle an arbitrary nesting depth. Perl provides a facility that allows 
regular expressions to recurse (amongst other things). It does this by interpolating Perl code in the 
expression at run time, and the code can refer to the expression itself. A Perl pattern to solve the 
parentheses problem can be created like this: 


$re = qr{\( (?: (?>[*() 1+) | (?p{$re}) )* \)}x; 


The (?p{...}) item interpolates Perl code at run time, and in this case refers recursively to the pattern in 
which it appears. Obviously, PCRE cannot support the interpolation of Perl code. Instead, it supports 
some special syntax for recursion of the entire pattern, and also for individual subpattern recursion. 


The special item that consists of (? followed by a number greater than zero and a closing parenthesis is 
a recursive call of the subpattern of the given number, provided that it occurs inside that subpattern. (If 
not, itis a "subroutine" call, which is described in the next section.) The special item (?R) is a recursive 
call of the entire regular expression. 


For example, this PCRE pattern solves the nested parentheses problem (assume the PCRE_EXTENDED 
option is set so that white space is ignored): 


VC ( (?>0*Q]+) | (?R) )* \) 


First it matches an opening parenthesis. Then it matches any number of substrings which can either be 
a sequence of non-parentheses, or a recursive match of the pattern itself (that is a correctly parenthesized 
substring). Finally there is a closing parenthesis. 


If this were part of a larger pattern, you would not want to recurse the entire pattern, so instead you could 
use this: 


User Guide for Cisco Security MARS Local Controller 
=u 78-17020-01 | 


| Appendix B 


Regular Expression Reference 


Subpatterns as Subroutines Tl 


We have put the pattern into parentheses, and caused the recursion to refer to them instead of the whole 
pattern. In a larger pattern, keeping track of parenthesis numbers can be tricky. It may be more 
convenient to use named parentheses instead. For this, PCRE uses (?P>name), which is an extension to 
the Python syntax that PCRE uses for named parentheses (Perl does not provide named parentheses). We 
could rewrite the above example as follows: 


(?P<pn> \( ( (?>[*()]+) | (?P>pn) )* \) ) 


This particular example pattern contains nested unlimited repeats, and so the use of atomic grouping for 
matching strings of non-parentheses is important when applying the pattern to strings that do not match. 
For example, when this pattern is applied to 


(aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa ( ) 


it yields "no match" quickly. However, if atomic grouping is not used, the match runs for a very long 
time indeed because there are so many different ways the + and * repeats can carve up the subject, and 
all have to be tested before failure can be reported. 


At the end of a match, the values set for any capturing subpatterns are those from the outermost level of 
the recursion at which the subpattern value is set. If you want to obtain intermediate values, a callout 
function can be used (see Subpatterns as Subroutines, page B-21 and the pcrecallout documentation). 
If the pattern above is matched against 


(ab (cd) ef) 


the value for the capturing parentheses is "ef", which is the last value taken on at the top level. If 
additional parentheses are added, giving 


the string they capture is "ab(cd)ef", the cont 


ents of the top level parentheses. If there are more than 15 capturing parentheses in a pattern, PCRE has 
to obtain extra memory to store data during a recursion, which it does by using pcre_malloc, freeing it 
via pere_free afterwards. If no memory can be obtained, the match fails with the 
PCRE_ERROR_NOMEMORY error. 


Do not confuse the (?R) item with the condition (R), which tests for recursion. Consider this pattern, 
which matches text in angle brackets, allowing for arbitrary nesting. Only digits are allowed in nested 
brackets (that is, when recursing), whereas any characters are permitted at the outer level. 


< (?: (?(R) \d+t+ | [<>] *+) | (?R)) * > 


In this pattern, (?(R) is the start of a conditional subpattern, with two different alternatives for the 
recursive and non-recursive cases. The (?R) item is the actual recursive call. 


Subpatterns as Subroutines 


If the syntax for a recursive subpattern reference (either by number or by name) is used outside the 
parentheses to which it refers, it operates like a subroutine in a programming language. An earlier 
example pointed out that the pattern 


(sens|respons)e and \libility 
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matches "sense and sensibility" and "response and responsibility", but not "sense and responsibility". If 
instead the pattern 


(sens|respons)e and (?1)ibility 


is used, it does match "sense and responsibility" as well as the other two strings. Such references must, 
however, follow the subpattern to which they refer. 


Perl has a feature whereby using the sequence (?{...}) causes arbitrary Perl code to be obeyed in the 
middle of matching a regular expression. This makes it possible, amongst other things, to extract 
different substrings that match the same pair of parentheses when there is a repetition. 


PCRE provides a similar feature, but of course it cannot obey arbitrary Perl code. The feature is called 
"callout". The caller of PCRE provides an external function by putting its entry point in the global 
variable pcre_callout. By default, this variable contains NULL, which disables all calling out. 


Within a regular expression, (?C) indicates the points at which the external function is to be called. If 
you want to identify different callout points, you can put a number less than 256 after the letter C. The 
default value is zero. For example, this pattern has two callout points: 


(?C1) \dabc (?C2) def 


If the PCRE_AUTO_CALLOUT flag is passed to pcre_compile(), callouts are automatically installed 
before each item in the pattern. They are all numbered 255. 


During matching, when PCRE reaches a callout point (and pcre_callout is set), the external function is 
called. It is provided with the number of the callout, the position in the pattern, and, optionally, one item 
of data originally supplied by the caller of pcre_exec(). The callout function may cause matching to 
proceed, to backtrack, or to fail altogether. A complete description of the interface to the callout function 
is given in the pcrecallout documentation. 


Last updated: 09 September 2004 
Copyright © 1997-2004 University of Cambridge. 
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The date/time field parsing is supported using the Unix strptime() standard C library function. 


The strptime() function is the converse function to strftime() and converts the character string pointed 
to by s to values which are stored in the tm structure pointed to by tm, using the format specified by 
format. Here format is a character string that consists of field descriptors and text characters, reminiscent 
of scanf(3). Each field descriptor consists of a % character followed by another character that specifies 
the replacement for the field descriptor. All other characters in the format string must have a matching 
character in the input string, except for whitespace, which matches zero or more whitespace characters 
in the input string. 


The strptime() function processes the input string from left to right. Each of the three possible input 
elements (whitespace, literal, or format) are handled one after the other. If the input cannot be matched 
to the format string the function stops. The remainder of the format and input strings are not processed. 


The supported input field descriptors are listed below. In case a text string (such as a weekday or month 
name) is to be matched, the comparison is case insensitive. In case a number is to be matched, leading 
zeros are permitted but not required. 


% % 
The % character. 
%a or %A 
The weekday name according to the current locale, in abbreviated form or the full name. 
%b or %B or %h 
The month name according to the current locale, in abbreviated form or the full name. 
Joc 
The date and time representation for the current locale. 
%C 
The century number (0-99). 
%d or %e 
The day of month (1-31). 
%D 


Equivalent to %m/%d/%y. (This is the American style date, very confusing to non-Americans, 
especially since %d/%m/%y is widely used in Europe. The ISO 8601 standard format is 
%Y-%om-%d.) 


%H 


I 78-17020-01 


User Guide for Cisco Security MARS Local Controller | 


AppendixC Date/Time Format Specfication | 


The hour (0-23). 
%I 

The hour on a 12-hour clock (1-12). 
%j 

The day number in the year (1-366). 
%m 

The month number (1-12). 
%M 

The minute (0-59). 
%n or %t 

Arbitrary whitespace. 
Jop 

The locale's equivalent of AM or PM. (Note: there may be none.) 
%r 


The 12-hour clock time (using the locale's AM or PM). In the POSIX locale equivalent to 
%1:%M:%S Vp. If t_fmt_ampm is empty in the LC_TIME part of the current locale then the 
behaviour is undefined. 


%R 
Equivalent to %H:%M. 
%S 
The second (0-60; 60 may occur for leap seconds; earlier also 61 was allowed). 
%T 
Equivalent to %H:%M:%S. 
%U 


The week number with Sunday the first day of the week (0-53). The first Sunday of January is the 
first day of week 1. 


Tow 
The weekday number (0-6) with Sunday = 0. 
%W 


The week number with Monday the first day of the week (0-53). The first Monday of January is the 
first day of week 1. 


%x 

The date, using the locale's date format. 
%X 

The time, using the locale's time format. 
Joy 


The year within century (0-99). When a century is not otherwise specified, values in the range 69-99 
refer to years in the twentieth century (1969-1999); values in the range 00-68 refer to years in the 
twenty-first century (2000-2068). 
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%Y 
The year, including century (for example, 1991). 


Some field descriptors can be modified by the E or O modifier characters to indicate that an alternative 
format or specification should be used. If the alternative format or specification does not exist in the 
current locale, the unmodified field descriptor is used. 


The E modifier specifies that the input string may contain alternative locale-dependent versions of the 
date and time representation: 


%Ec 

The locale's alternative date and time representation. 
%EC 

The name of the base year (period) in the locale's alternative representation. 
%Ex 

The locale's alternative date representation. 
%EX 

The locale's alternative time representation. 
%Ey 

The offset from %EC (year only) in the locale's alternative representation. 
EY 

The full alternative year representation. 
The O modifier specifies that the numerical input may be in an alternative locale-dependent format: 
%Od or %Oec 


The day of the month using the locale's alternative numeric symbols; leading zeros are permitted but 
not required. 


%OH 

The hour (24-hour clock) using the locale's alternative numeric symbols. 
%OI 

The hour (12-hour clock) using the locale's alternative numeric symbols. 
%Om 

The month using the locale's alternative numeric symbols. 
%OM 

The minutes using the locale's alternative numeric symbols. 
%OS 

The seconds using the locale's alternative numeric symbols. 
%OU 


The week number of the year (Sunday as the first day of the week) using the locale's alternative 
numeric symbols. 


%Ow 
The number of the weekday (Sunday=0) using the locale's alternative numeric symbols. 


%oOW 
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The week number of the year (Monday as the first day of the week) using the locale's alternative 
numeric symbols. 


% Oy 


The year (offset from %C) using the locale's alternative numeric symbols. 


%¥F 
Equivalent to % Y-%m-%d, the ISO 8601 date format. 
Tog 
The year corresponding to the ISO week number, but without the century (0-99). 
%G 
The year corresponding to the ISO week number. (For example, 1991.) 
%u 
The day of the week as a decimal number (1-7, where Monday = 1). 
%NV 


The ISO 8601:1988 week number as a decimal number (1-53). If the week (starting on Monday) 
containing | January has four or more days in the new year, then it is considered week 1. Otherwise, 
it is the last week of the previous year, and the next week is week |. 


tL 

An RFC-822/ISO 8601 standard time zone specification. 
L 

The timezone name. 


Similarly, because of GNU extensions to strftime, %k is accepted as a synonym for %H, and %1 should 
be accepted as a synonym for %I, and %P is accepted as a synonym for %p. Finally 


%s 


The number of seconds since the epoch, i.e., since 1970-01-01 00:00:00 UTC. Leap seconds are not 
counted unless leap second support is available. 
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5-tuple 


A 


Access IP Address 


Activate 


D 


Devices 
Discovery 
Dynamic 


Vulnerability 
Scanning 


Event 


Event Types 


F 


False Positive 


Firing Events 


GLOSSARY 


(Quintuple) The five pieces of data found within all IP-based network packets: source IP address, 
source port, destination IP address, destination port, and protocol. You can define inspection rules, 
queries, and reports using the data found in the 5-tuple. 


(\ 
This is the IP address that MARS uses to connect to the device and to get its configuration information. 
MARS needs this address for NAT-related session correlation, attack path calculation, and mitigation 


enter access information. 


Making changes or edits known to the MARS after submitting changes. 


The hosts and reporting devices present in the system. 
The act of identifying, either automatically or manually, devices in networks. 


The MARS STM probes selected networks, and their components, for vulnerabilities. 


A security event reported to the MARS STM appliance. Events have: types, sources, destinations, 
reporting devices, etc. 


Groups of similar security events. An event type is the normalized signature from a reporting device. 


An event that resembles a valid security threat, but is not. 


An event that contributed to a rule firing. 
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Incident Incidents are collections of events and sessions that meet the criteria for a rule, having helped to cause 
it to fire. 


Incident Instances An instance of an incident. 


M 

MIB management information base 

mitigate To stop a detected attack or anomaly. The method of mitigation varies based on network composition 
and configuration. 

O 

Offset The offset of a firing event is the line number of the rule criteria that this firing event matches. 

P 

Pre NAT Source Session endpoints. 

Address 

Post NAT Source The source as appearing at the destination. 

Address 

Post NAT Session endpoints. 


Destination Address 


Pre NAT Destination The destination as appearing at the source. 


Address 

Q 

Query A user-defined request to the database for information. 

R 

Report A user-defined request to the database on an automatic or on-demand basis. 


Reporting Device A discovered device that reports information — usually in the form of logs — toa MARS STM appliance. 
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Reporting IP 
Address 


Rule 


=) 


Service 


Session 


Sessionize 


T 


True Positive 


U 


Unreported device 


T 


True Positive 


Glossary Hi 


This is the IP address as it appears to MARS. This address is where the logs (syslog, SNMP traps, LEA) 
come from. 


The sub-set of events that contributed to the incidents of the specified rules firing. 


A protocol and range of IP addresses. 


A session is a collection of events that all share a common source and destination, which were reported 
within a given time window. For example, usually the events in a session map well to the events 
generated between the opening and closing of a TCP/IP connection. 


Combining event data from multiple reporting devices to reconstruct the occurrence of a session. 
Sessionizing takes two forms: reconstructing a session-oriented protocol, such as TCP, where the initial 
handshake and the session tear down and reconstructing a sessionless protocol, such as UDP, where the 
initial start and session end times are defined more based on first and last packets tracked within a 
restricted time period. In other words, packets that fall outside of the time period are considered part 
of different sessions. 


A valid security threat. 


A device from which the MARS Appliance receives events, such as syslog messages, SNMP 
notifications, or NetFlow events, but the device is not defined in the appliance. Without a definition, 
MARS is unable to correlate events correctly as it needs to know which message format to use in 
parsing. 


A valid security threat. 
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